MCP inventory
An MCP inventory is a continuously updated record of every Model Context Protocol server in an organization: the tools each server exposes, the credentials it authenticates with, who owns it, which agents may call it, and whether it is sanctioned. It records servers and tools. An agent inventory records the agents that call them.
An endpoint scan of an engineer’s laptop may list Cursor on the software register, while the same machine has a GitHub Model Context Protocol (MCP) server configured in ~/.cursor/mcp.json. That server can authenticate with a personal access token that reads and writes every repository the engineer can. The software register records the client, while an MCP inventory records the server, its tools, and the credential behind its access.
The public MCP Registry serves a different purpose. It shows which servers are available to install, while an MCP inventory records server identity, connected agents, exposed tools, authentication state, and sanctioned status in one organization. Security teams need that record to govern the servers and tools their agents call.
This guide focuses on servers and tools. The agent inventory covers the agents that call them.
Together, the two records make MCP security policies enforceable: a policy needs to know which servers exist, which tools they expose, and which agents can call them.
Why can’t a CMDB or the public MCP Registry serve as an MCP inventory?
A configuration management database (CMDB) and software asset inventory track installed software. An MCP server can be a few lines of JSON in a dotfile or a remote URL. A local stdio server tells an agent which package to execute, while a remote server appears as a runtime connection. Asset scans capture the editor. The servers, tools, and credentials it reaches remain outside the record. Our guide on shadow AI covers the wider detection problem.
The public MCP Registry is a catalog that vendors and open-source maintainers publish to so clients and aggregators can discover servers. An enterprise MCP inventory covers the servers that are actually running in one organization, including:
- Local stdio servers configured in dotfiles such as
~/.cursor/mcp.json - Remote servers reached by URL, hosted by SaaS vendors
- Internal servers the organization built or generated from its own APIs
- Hosted connectors bundled inside SaaS agent platforms
The inventory records which candidates were approved, what each one authenticates with, and whether agents are actually calling it.
What belongs in an MCP inventory record?
Each MCP inventory record needs the fields a security team will query when a credential leaks or a tool becomes destructive:
- Server identity. The URL for a remote server, or the package specifier and version for a local one. This identifier ties the record together across renames and vendor migrations.
- Transport. A stdio server runs as a child process on the endpoint, while a remote server is an HTTP endpoint elsewhere. Transport determines where the credential lives and which controls can observe the traffic.
- Tools and their disposition. Every tool the server exposes, including whether it only reads or can create, modify, or delete data. A server whose tools are all read-only needs a different review from one exposing
create_refund. Tool lists can change over time, so this field needs a live feed. - Credential and auth method. OAuth on the caller’s own identity, a managed API key, or a personal access token in a dotfile. The record should name the identity the server presents upstream. A shared credential makes every caller appear as the same actor, the failure covered in what is NHI.
- Human owner of record. The person who answers for the server, renews its review, and retires it. An owner field keeps review and retirement work assigned when teams change.
- Connected agents. Which agents and clients are allowed to call the server. This field links to the agent inventory, and each agent record links back.
- Sanctioned status. Whether the organization approved the server. Approved servers and discovered ones sit in the same register with different dispositions.
- Last seen. When the server last served a call. A dormant server is a revocation candidate, while an active server without approval needs investigation.
MCP inventory vs agent inventory vs shadow MCP: what’s the difference?
An MCP inventory answers which servers expose a destructive tool and what each one authenticates with. An agent inventory answers which agents can touch billing and who owns each one. The records link to each other: each server record identifies the agents that can call it, and each agent record identifies the servers it reaches.
The diagram shows why the records need to link. The agent inventory answers who is acting. The MCP inventory answers what it can call and how that server authenticates. Together, they show the path from an agent to the systems and data it can reach.
Shadow MCP means unsanctioned servers operating outside formal security governance. Discovery surfaces those servers one finding at a time. The MCP inventory turns each finding into a record with an owner and a disposition, alongside every approved server. What is shadow AI explains endpoint discovery, MCP risk approval shows how a finding becomes a scoped decision, and what is an MCP gateway explains enforcement in front of the servers.
How does an MCP inventory stay current?
A static MCP inventory ages quickly. A spreadsheet compiled for an audit is accurate on the day it is finished and describes last quarter by the time anyone reads it. Because wiring up a new server is a config-file edit, a register maintained by survey decays in weeks. Staying current requires two live feeds:
- Discovery on the endpoint. Agent hooks fire inside coding agents on every prompt and tool call. They can report the MCP servers a session is actually wired to, including servers that never passed review. The shadow AI reference describes this architecture end to end.
- The sanctioned path. When agents reach tools through a gateway, every session and tool call passes a point that can record the server, tool, and caller. Traffic then keeps the sanctioned-server records and last-seen field current.
How does an MCP inventory support MCP security?
An MCP inventory makes an allow-or-block policy enforceable. A policy can block a call to a server with no record or a record marked unsanctioned. It also supports least privilege at tool granularity, allowing a policy to grant get_invoice without granting create_refund, one of the six controls in MCP security.
When a server is compromised or rug-pulled, its record is where the organization revokes access. When an assessor asks which servers agents can reach and what each authenticates with, the inventory provides the evidence.
How does the Speakeasy AI Control Plane keep the MCP inventory live?
An organization can assemble this architecture from its existing systems. The Speakeasy AI Control Plane provides it as one system and maintains the MCP inventory as servers are added and called:
- The gateway is the register of sanctioned servers. Servers enter the MCP gateway in three ways: generation from the OpenAPI documents the organization already has, adding an existing vendor server remote by URL, or import from a catalog powered by the official MCP Registry. The catalog identifies a candidate server. The gateway row, with its tools, credential, owner, and traffic, becomes the inventory record.
- Shadow MCP detection fills the unsanctioned half. Shadow MCP detection recognizes, from instrumented agent traffic, when a session connects to a server outside the sanctioned setup, and surfaces it by URL, host, or resolved identity. Allow and deny rules then apply at runtime. If policy evaluation is unavailable, the organization’s fail-open or fail-closed setting determines whether the call proceeds; explicit denials and invalid credentials still block.
- Identity and credentials sit on the gateway. Upstream auth is provisioned per server through one-click OAuth on the user’s own identity, a managed credential stored once, or header pass-through. Each inventory row carries a named owner and a known auth method.
The MCP inventory is built from live traffic, so it stays useful between reviews. To see the inventory the platform maintains for the servers your agents already call, talk to us.