Mapping · architecture
MCP Capability Graph: Mapping What Your AI Can Actually Do
A list tells you what exists. A graph tells you that three teams built the same thing, that one server sits under nine workflows, and that an agent nobody classified as sensitive can reach the payments ledger in two hops.
The short answer
An MCP capability graph models an estate as nodes — agents, capabilities, tools and backing systems — connected by entitlement, implementation and dependency edges. It answers questions a flat inventory cannot: which capabilities have duplicate implementations, which tools no agent can reach, which single server sits under many workflows, and which privilege paths exist between an agent and a sensitive system. Build it from the registry plus a month of call logs. Four node types, three edge types, five questions that only structure can answer.
Why a list stops being enough
An inventory is a table: one row per server or tool, columns for owner, risk, version. Everything you need for entitlement decisions, and structurally incapable of answering anything relational.
Which is unfortunate, because the expensive problems in an MCP estate are relational. Duplicate implementations of the same capability are a relationship between two tools. A single point of failure is a relationship between one server and many workflows. A privilege path is a chain of relationships from an agent through tools to a system nobody intended it to reach. None of these are visible in a table, however well maintained, because a table has no place to put the edges.
A graph is not a bigger inventory. It is the same data with the relationships made explicit, which turns four or five expensive audit questions into queries.
Four node types, three edge types
Deliberately small. Every additional node type we have tried adding made the graph harder to keep current without answering a new question.
| Element | What it is | Why it is separate |
|---|---|---|
| Node: Agent | An identity that makes calls — a named agent, a workflow, a human-triggered assistant. | The subject of every entitlement question. |
| Node: Capability | The logical action: issue refund, read customer record. Not a tool. | The layer where duplication becomes visible. Two tools, one capability. |
| Node: Tool | A concrete tool on a concrete server, with a schema and a risk class. | What is actually called, and the unit policy operates on. |
| Node: System | The backing system where consequences land: a ledger, a CRM, a mailbox, a bucket. | Where blast radius is measured, and where residency lives. |
| Edge: entitled-to | Agent → capability. Carries conditions: environment, threshold, approval requirement. | Entitlement belongs on capability, not on tool, or it breaks whenever routing changes. |
| Edge: implements | Tool → capability. Carries the route preference. | One capability, several implementing tools. This edge is the duplication detector. |
| Edge: reaches | Tool → system, with the credential scope on the edge. | Scope is a property of the connection, not of the tool or the system alone. |
The single most important modelling decision is putting capability between agent and tool. Entitle agents to capabilities and the graph survives re-routing, server consolidation and vendor swaps. Entitle them directly to tools and every infrastructure change becomes an entitlement migration.
Five questions only a graph answers
Each of these has produced a real decision for us or for someone we have worked with. Each is close to unanswerable from a table.
Which capabilities have more than one implementing tool?
Duplication, exactly. Three teams each built a customer-lookup tool, and your agents pick between them on description quality. This query is also the input to any consolidation business case, because it quantifies the duplication rather than asserting it.
It is not automatically a problem — multiple implementations may be deliberate redundancy. The question is whether the duplication is chosen or accidental, and the graph is what makes that distinguishable.
Which tools are reachable by no agent?
Orphans. Every one is a credential still valid, a dependency still patched, and an attack surface with no offsetting value. Usually 10–20% of the tool count in an estate over a year old.
Revoke the credential before removing the tool. Cheaper to reverse, and it surfaces a real user within a day if one exists.
Which single tool or server sits under the most capabilities?
Concentration risk, quantified. If one server implements eleven capabilities used by six agents, its maintenance window is an outage for six workflows and nobody has written that down anywhere.
What is the shortest path from this agent to that system?
Privilege-path analysis, borrowed from attack-graph practice. Ask it of every agent against every sensitive system. The surprising answers are almost always a tool whose reach nobody had connected to that system — a document tool that can read a bucket that contains an export of the ledger.
If this server were removed, which capabilities would have no route?
Change-impact analysis before the change rather than during it. Also the fastest way to find capabilities with exactly one route, which is the set worth adding redundancy to first.
Building it in a week
This does not need a graph database or a platform team. It needs two inputs you already have and one deliberate act of naming.
- 01Start from the registry. Servers, tools, owners, risk classes, credential scopes. Tools and systems become nodes; reaches edges come from the credential scope column. See the registry record.
- 02Derive capabilities by naming them. The only genuinely manual step. Group tools that do the same logical thing and name the group. Twenty to forty capability names usually cover an estate of a few hundred tools, and the grouping argument is itself valuable.
- 03Get entitlement edges from the gateway. Which identities are permitted which capability, with conditions. If nothing records this, that is the more urgent finding.
- 04Add observed edges from a month of call logs. Entitlement is what is permitted; call logs are what is used. The difference between the two graphs is your over-entitlement, and it is usually large.
- 05Keep it in the same store as the registry. A separate graph system becomes a stale copy within a quarter. Two joins on existing tables beat a beautiful graph nobody updates.
Built on this thinking
The graph is only current if one layer sees every call
Barzel Central Gateway holds the registry, the capability-to-tool mapping and per-identity entitlement, and its call record supplies the observed edges — so permitted-versus-observed is a query rather than a project. Twenty-five tools, free Community tier.
Permitted versus observed: the gap that matters
Two graphs over the same nodes. The permitted graph is what entitlement allows. The observed graph is what call logs show actually happened over the last month. The difference is the most actionable artefact in this entire exercise.
Edges permitted but never used are over-entitlement, and they are cheap to remove because nothing depends on them. In practice this is the least painful least-privilege work available: you are revoking access to tools nobody has called in thirty days, and the conversation is short.
Edges observed but not permitted should be impossible. Any that exist mean something is bypassing the enforcement point, which is a finding that outranks everything else on this page.
Run the diff monthly and act on the first category. The second should be empty, and verifying that it is empty is a five-minute check worth doing every month for as long as the estate exists.
Four mistakes worth naming
Entitling agents to tools instead of capabilities
Every routing change, server consolidation or vendor swap becomes an entitlement migration. Put capability in the middle.
Modelling the graph nobody queries
Build it for the five queries. Node types that answer no question are node types that will not be maintained.
Deriving capabilities automatically
Clustering tool descriptions produces plausible groups that nobody agrees with. The naming argument is the value; skipping it skips the point.
Permitted graph only
Without the observed graph there is no over-entitlement analysis and no way to detect a bypass of the enforcement point.
Frequently asked questions
What is an MCP capability graph?
A graph representation of an MCP estate in which agents, capabilities, tools and backing systems are nodes, connected by entitlement, implementation and dependency edges. It makes relational questions — duplication, concentration risk, privilege paths — queryable in a way a flat inventory cannot.
What node and edge types does a capability graph need?
Four nodes: agent, capability, tool and system. Three edges: entitled-to from agent to capability with its conditions, implements from tool to capability with route preference, and reaches from tool to system carrying the credential scope.
Why put capability between agent and tool?
So entitlement survives infrastructure change. Entitle agents to capabilities and re-routing, server consolidation or a vendor swap leaves entitlement untouched. Entitle them directly to tools and every infrastructure change becomes an entitlement migration.
How does a capability graph reveal duplicate MCP tools?
Query for capabilities with more than one implementing tool. Duplication is a relationship between tools, so it is invisible in a table and obvious in a graph. Multiple implementations may be deliberate redundancy — the graph is what makes chosen duplication distinguishable from accidental duplication.
What is the difference between the permitted graph and the observed graph?
The permitted graph is what entitlement allows; the observed graph is what call logs show happened over the last month. Edges permitted but never used are over-entitlement and are cheap to revoke. Edges observed but not permitted mean something is bypassing the enforcement point, which outranks every other finding.
How do you build an MCP capability graph?
Start from the registry for tools, systems and credential scopes; name capabilities manually by grouping tools that do the same logical thing; take entitlement edges from the gateway; add observed edges from a month of call logs; and keep it in the same store as the registry rather than in a separate graph system that will go stale.
Should capabilities be derived automatically from tool descriptions?
No. Clustering descriptions produces plausible groups nobody agrees with. Twenty to forty named capabilities usually cover an estate of several hundred tools, and the argument about how to group them is where most of the value is.
What proportion of MCP tools are typically unreachable by any agent?
In estates over a year old we typically see 10–20% of tools with no entitled caller. Each one is a live credential and a patched dependency with no offsetting value. Revoke the credential before removing the tool — it is cheaper to reverse and surfaces a real user within a day.
Sources and further reading
Graph-based asset and dependency modelling is long-standing practice in configuration management and attack-path analysis; the sources below cover the general form. The node and edge model here, and the five queries, are our own.
- 01 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 02 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
- 03 · Kubernetes projectKubernetes — cluster architecture ↗The canonical control-plane / data-plane separation, and the closest well-understood analogue.
- 04 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 05 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 06 · MITREMITRE ATLAS ↗Adversary technique knowledge base for AI systems, useful for naming what a risk score is scoring.
- 07 · OpenTelemetryOpenTelemetry — GenAI semantic conventions ↗Emerging standard attribute names for model and tool-call telemetry.
Last reviewed 24 August 2026. External links open in a new tab; we do not control their content.
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so the evaluation costs an afternoon rather than a purchase order.
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.