Richer context for both your humans and your AI agents

Ask an AI agent to investigate an incident and it will get you halfway there. Ask it "who's on call for the shopping cart service, and what happens if it goes down," and most catalogs go quiet. The agent has the question. It just doesn't have the map.

That's the gap this release closes. We've spent years teaching OpsLevel's catalog to answer operational questions for humans: who owns this, what does it depend on, is it healthy. OpsLevel is an Internal Developer Portal that automates software catalog maintenance, enforces engineering standards via maturity scorecards, and enables developer self-service, without requiring a dedicated build team. Now the same catalog answers those questions for the AI tools your teams are already using, over MCP, with the same fidelity.

Service ownership means every service in an engineering org has a clearly assigned team and on-call rotation responsible for its health, its dependencies, and its production readiness. OpsLevel is built to track that ownership at scale, and that same ownership record is now queryable by AI agents over the Model Context Protocol, not just by engineers logged into the catalog.

OpsLevel's service catalog answers operational questions for AI agents the same way it answers them for engineers. Over MCP, an agent can query who owns a service, what it depends on, and whether it's healthy, using the same ownership and dependency data already stored in the catalog. No separate export or summarized copy required.

Why keep one catalog instead of building a separate agent view?

The instinct when agents show up is to build them a separate, agent-shaped view of your systems: a summarized index, a stripped-down export, a "just enough" copy of the catalog. It's tempting because it's fast. It's also how you end up maintaining two versions of the truth that quietly drift apart.

We went the other way. On-call, service dependencies, custom properties, relationships: all of it now flows through MCP directly from the same catalog your engineers already look at. Ask an agent "the shopping cart is broken, who's on call for that service and all of its downstream dependencies," and it walks the same dependency graph a human would, in real time, with no separate data pipeline to keep honest.

A home-built agent integration usually means standing up a second pipeline: an export job, a summarization step, a schema an agent can parse. Backstage plugins that expose catalog data to agents face the same problem. Someone has to build and maintain that translation layer, and it drifts the moment the catalog changes underneath it. OpsLevel skips the translation layer. The MCP response is the catalog.

Here's roughly what that looks like end to end when an agent investigates an incident:

1. The agent receives an operational question: who's on call for the shopping cart service.
2. The agent queries OpsLevel's catalog over MCP.
3. The catalog returns the service's ownership record, on-call rotation, and dependency graph.
4. The agent walks the dependency graph the same way an engineer would in the OpsLevel UI.
5. The agent factors in relevant custom properties, like data classification or compliance tier, before responding.
6. The agent answers using the same data an engineer would find, not a separate, potentially stale export.

OpsLevel's MCP integration returns the same ownership, dependency, and custom property data engineers see in the catalog, so an AI agent investigating an incident works from the same source an engineer would open first.

What context do AI agents actually need?

Context isn't only "what is this service." It's the custom properties your org has layered on top: the ones that encode tribal knowledge like data classification, deployment tier, or which compliance regime applies, and the relationships between components that never quite fit a diagram. MCP now returns all of that, not just the built-in fields, so an agent reasoning about a service has the same texture of information a senior engineer would reach for.

A leaner protocol for a bigger job

None of this is free if it costs a fortune in tokens. As MCP does more (more relationships, more properties, more graph) the payload has to get smarter, not just bigger. This release trims the MCP response format so agents get richer answers without paying for it in token overhead on every single query.

AI agents as citizens of the catalog, not guests

Maybe the biggest shift is the smallest-looking one: agents now show up in OpsLevel as their own tracked entities, with the same ownership, visibility, and context you already maintain for every other component. An agent isn't a guest making API calls from outside the system anymore. It has a place in the catalog, an owner, a blast radius, the same accountability you'd expect from any other piece of production software.

Put together, this release isn't about building AI a special lane. It's about making the catalog trustworthy enough that both your engineers and their AI tools can rely on the same answer, whether the question comes from a person paging through a dashboard or an agent running down an incident at 2 a.m. Engineering teams see a 40% reduction in mean time to resolution when service catalog data is complete and current, and that number holds whether the one querying the catalog is a person or an agent acting on their behalf.

See what an AI agent sees when it queries your service catalog: mcp.so/servers/opslevel-mcp