Architecture, ownership and SLA servers run as products

Servers for architecture, ownership and SLA data are run as products: versioned, owned and monitored. The organisation has moved past the stage where an MCP server is a script somebody wrote on a Friday and now runs on their laptop, and treats each one as a piece of production infrastructure with a name on it, a release history, and a dashboard.

The distinction this level draws is operational, not editorial. What context an agent should receive, in what order, and how much of the window it deserves is Context Engineering's question, and this guide does not try to answer it. What is answered here is everything the server side owes its callers: that the tool contract does not change without warning, that somebody is accountable when it breaks, that its latency and error rate are visible, and that a caller can tell whether the data behind it is current.

The servers themselves are organised by knowledge domain rather than by whichever data source was easiest to mirror: an architecture server that knows the design decisions and ADRs, an ownership server that knows which team owns which service, and an SLA server that knows the reliability contracts and performance budgets for each component. Splitting them this way is partly an operational choice. Each has a different natural owner, a different change rate, and a different failure mode, and one combined server means one team is on the hook for all three.

The architecture server 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 server 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 server 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.

• A server agents depend on is production infrastructure - once agent workflows call it routinely, an unowned server that goes down or silently changes its output is an outage with no on-call, and it will be diagnosed as "the agents got worse this week"
• Versioning is what lets the contract change safely - tool names, parameters and response shapes are an API that agents and prompts are written against; changing them without a version is a silent breakage that surfaces as degraded output rather than as an error
• Reduces the "ask a senior engineer" bottleneck - agents with architecture, ownership and SLA data can answer many questions that currently require interrupting a senior engineer, but only for as long as the servers are actually up and current
• 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, ownership and SLA data evolve at different rates and belong to different teams; separate servers make each one's owner obvious and let each be versioned and retired on its own schedule

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. Version the tool contract from the first release - Tool names, parameter shapes and response schemas are an API. Publish a version, treat a changed field name or a removed parameter as a breaking change, and keep the previous version serving until callers have moved. Silent contract changes do not raise errors; they degrade the output of every agent that was written against the old shape, weeks before anyone connects the two.
6. Give each server a named owning team and put it on their dashboard - Ownership means a team that is paged when the server is down, reviews changes to its schema, and decides when it is retired. Monitor what you would monitor for any service - availability, p99 latency, error rate, call volume by tool - plus one metric specific to this kind of server: the age of the data behind each response. Falling call volume is worth an alert of its own, because it usually means agents have quietly stopped finding the server useful.
7. Publish a deprecation path before you need one - Servers get replaced, merged and retired. Decide up front how a caller learns that a tool is going away, how long the overlap is, and where the replacement lives. Without this, the first retirement is an incident and the second one is a reason nobody trusts the platform.

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.

Running it as somebody's side project. The usual origin story is a useful script that quietly became load-bearing. Nobody is on call, it runs on infrastructure nobody has audited, and its author has since changed teams. Agents keep calling it, get slower and worse answers, and the degradation is attributed to the model. The fix is unglamorous: give it an owner, deploy it like a service, and monitor it.

Changing the tool contract without a version. Renaming a parameter or restructuring a response is invisible to the agent's error handling and highly visible in its output quality. Version the contract, deprecate rather than delete, and treat schema changes with the same care as a public API change.

Monitoring uptime but not usefulness. A server can be green on every infrastructure metric while returning data that is nine months old, or while no agent has called it in a fortnight. Track staleness of the backing data and call volume per tool alongside the usual signals, since those are the two ways this class of server fails while looking healthy.

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.