infrastructureL3 SystematicMCP & Tool Integration

Architecture MCP, Ownership MCP, SLA MCP

Specialized MCP servers organized by knowledge domain represent the L3 evolution from general-purpose data access to structured organizational intelligence.

·Centralized MCP platform manages server provisioning, configuration, and lifecycle
·Domain-specific MCP servers exist (Architecture MCP, Ownership MCP, SLA MCP)
·RBAC controls which agents can access which MCP tools

·MCP server health is monitored with alerting on downtime
·New MCP servers go through a standardized review and onboarding process

Evidence

·MCP platform configuration showing centralized server management
·RBAC policy configuration for MCP tool access
·MCP server inventory listing domain-specific servers with owners

What It Is

Specialized MCP servers organized by knowledge domain represent the L3 evolution from general-purpose data access to structured organizational intelligence. Rather than one server that exposes everything, or three servers that mirror the most convenient data sources, the organization builds purpose-specific servers that encode different types of institutional knowledge: an Architecture MCP that knows the system design decisions and ADRs, an Ownership MCP that knows which team owns which service, and an SLA MCP that knows the reliability contracts and performance budgets for each component.

The Architecture MCP is the institutional memory for technical decisions. It exposes Architecture Decision Records (ADRs), system diagrams, service dependency maps, and rationale for major technical choices. When an agent is implementing a feature that touches a system boundary, it queries the Architecture MCP to understand what constraints apply, what patterns are established, and what decisions have already been made. Without this server, agents either make assumptions based on code they can see (which often doesn't encode the "why") or ask developers who have to look it up themselves.

The Ownership MCP answers "who owns this?" - a question that comes up constantly in large systems. Which team is responsible for the payment service? Who is the on-call for the authentication system? Who should review a change to the data pipeline? In organizations where ownership is in a spreadsheet, a Notion page, or a CODEOWNERS file in one specific repo, agents have no reliable way to answer this question. An Ownership MCP with a consistent API (input: service name or file path; output: team name, Slack channel, on-call rotation) makes this answerable programmatically.

The SLA MCP exposes the reliability contracts and performance expectations for each service. What is the p99 latency target for the checkout API? What error rate triggers an alert? What is the data retention policy for this database? Agents that know SLA constraints can write code that respects them: they'll suggest appropriate timeout values, add the right error handling, and flag when a proposed change would violate a constraint. Without this context, agents write code that works functionally but may silently violate operational requirements.

Why It Matters

Makes institutional knowledge queryable by agents - decisions, ownership, and SLAs are typically stored in formats that humans can read but agents cannot query; specialized MCP servers make this knowledge accessible to agents at the moment they need it
Reduces the "ask a senior engineer" bottleneck - agents with Architecture, Ownership, and SLA context can answer many questions that currently require interrupting a senior engineer; the knowledge is available on demand without human mediation
Produces better agent code by default - an agent that knows the SLA for a service it's modifying will write code that respects that SLA; an agent that knows the ownership structure will route questions to the right team automatically
Creates feedback loops that improve documentation - when agents actively query ADRs, ownership docs, and SLA definitions, teams discover gaps and outdated entries quickly because the gaps produce bad agent behavior; this motivates keeping the documentation current
Separates concerns cleanly - architecture knowledge, ownership knowledge, and SLA knowledge evolve at different rates and are owned by different teams; separate servers make it easier to keep each current and assign clear ownership

Getting Started

Audit what institutional knowledge currently lives where - before building servers, map the landscape: where are your ADRs? Is ownership in a CODEOWNERS file, a spreadsheet, a Backstage catalog? Where are SLA definitions documented? This audit reveals both what to build servers for and how much work is required to normalize the data.
Start with the Ownership MCP - ownership information is highly structured, changes relatively rarely, and has a clear schema. A simple server that reads from a CODEOWNERS file or a service catalog JSON file and returns the owning team for a service or file path is achievable in a day and immediately useful.
Build the Architecture MCP around your ADR directory - most engineering teams have an ADR directory even if it's not well maintained. A server that indexes ADRs and makes them searchable by keyword, by decision date, or by affected component is the minimum viable Architecture MCP.
Normalize SLA definitions into a machine-readable format - SLAs are often documented in prose. For the SLA MCP, create a structured format: a YAML or JSON file per service defining latency targets, error rate budgets, data retention policies, and alert thresholds. The act of writing this format often reveals that SLAs aren't actually defined for many services - which is itself a valuable discovery.
Write rich tool descriptions for each server - the agent uses the tool description to decide when to call the server. A description like "use this tool to find the team responsible for a service or component, for routing questions and review requests" is much more effective than "ownership lookup." Good descriptions are half the value of specialized servers.
Establish update processes for each server - an Architecture MCP that returns outdated ADRs is worse than no Architecture MCP, because the agent will confidently give wrong answers. Define who updates each server, what triggers an update (a new ADR, a service ownership change, an SLA revision), and how to verify the server's data is current.

Tip

Use the Backstage software catalog as the data source for both your Ownership MCP and your Architecture MCP if your organization uses Backstage. Backstage's structured catalog is exactly the kind of normalized, queryable data that makes a great MCP server backend.

6 steps to get from here to the next level

Common Pitfalls

Building servers for knowledge that doesn't exist yet. If your organization doesn't have ADRs, building an Architecture MCP server is premature - there's nothing to serve. Start with whatever institutional knowledge is currently written down, even if it's in imperfect shape. A server that exposes 20 well-written ADRs is more valuable than a server that exposes 200 inconsistently-formatted documents.

Making the schema too rigid. Ownership structures evolve; teams reorganize; services get renamed. An Ownership MCP with a rigid schema that requires a three-day update process when a team changes ownership will quickly become outdated. Design the schema to be simple to update: a flat YAML file with service-to-team mappings is more maintainable than a complex relational structure.

Not linking the servers together. The value of specialized servers compounds when they're used together. An agent resolving an incident should be able to query the Ownership MCP to find who to contact, then query the SLA MCP to understand what the target resolution time is, then query the Architecture MCP to understand the affected system topology. This cross-server reasoning is powerful but only works if the agent's prompting encourages it to use all available tools.

Treating server output as authoritative when it's stale. An agent that reads an outdated ADR and acts on it as if it's current will make wrong decisions confidently. Embed freshness metadata in server responses: the date the entry was last updated, and optionally a flag if it's older than a defined threshold. Agents that see "last updated 14 months ago" will handle the information with appropriate skepticism.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team frequently gets stuck when implementing features that cross service boundaries. Developers need to understand which team owns adjacent services, what the SLA constraints are, and what architectural decisions govern the interface. Currently they ask around in Slack, which is slow and interrupts the people being asked.

What Bob should do: Bob should sponsor a one-sprint project to build all three specialized servers and measure the impact on inter-team coordination overhead. The metric: count how many Slack messages per week ask about service ownership, SLA constraints, or architectural decisions. After deploying the servers, run the same count. The reduction is the direct productivity impact. Bob should also require that these servers be used in the team's standard agent workflows: when an agent is implementing a feature that touches another service, it should query the Ownership MCP before generating code. This "query first" standard is the mechanism that turns server deployment into actual productivity gain.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is trying to improve the accuracy of agent-generated code that touches service boundaries. Agents frequently write integration code that violates the actual SLAs or uses patterns that the architecture team has deprecated. These errors are caught in code review, creating rework cycles.

What Sarah should do: Sarah should work with the architecture and reliability teams to create the structured data that the specialized MCP servers need. The SLA MCP requires SLA definitions in a machine-readable format - if those don't exist, Sarah should run a workshop to create them. The Architecture MCP requires ADRs - if they're incomplete, Sarah should drive an effort to bring them current. This is not an AI infrastructure project; it's a documentation quality project that pays dividends both for human engineers and for the agents that will use it. The MCP servers are the delivery mechanism; the underlying structured knowledge is the actual value.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has already implemented a basic Architecture MCP that reads from the ADR directory and an Ownership MCP that reads from the CODEOWNERS file. They work, but he finds that agents only use them when explicitly prompted to do so. Agents default to their training knowledge rather than querying available tools.

What Victor should do: Victor should address the tool usage problem at the system prompt level. Add explicit instructions to the agent's system context: "before implementing any feature that touches a service boundary, query the architecture MCP for relevant ADRs and the ownership MCP for the responsible team." Agents follow explicit instructions more reliably than they make tool-use inferences. Victor should also improve the tool descriptions to include specific trigger conditions: "call this tool when you need to know who owns a service, before sending review requests or raising questions about another team's code." Better descriptions combined with explicit system-level prompting close the gap between "server exists" and "server gets used."

What Victor should do - role-specific action plan