Architecture MCP, Ownership MCP, SLA MCP

April pushed MCP from "code tools" into deep-system access. Three notable additions to the public ecosystem:

• pentester-mcp - hundreds of offensive-security functions exposed to coding agents
• windbg-mcp - kernel-level debugging primitives for Windows targets
• Pepper - real-time iOS runtime inspection from agent context

OAuth/token-persistence issues in Claude's web interface drove adoption of mcp-auth-proxy middleware. On the performance side, Rust-based context retrievers (webclaw, ferris-search) and Go orchestrators (jig) emerged for low-latency multi-agent profiles. The signal for L3 maturity is no longer "do you have Architecture/Ownership/SLA MCPs?" but "are your MCPs governed and secure enough to safely expose deep-system surface area?"

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.

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.