What is the difference between an MCP inventory and an agent inventory?

An MCP inventory records tools: the MCP servers in use, what each one exposes, and the credentials behind it. An agent inventory records principals: the agents themselves, the identity each runs as, and who owns it. They are two halves of one map, and each record points at the other. A server record lists the agents allowed to call it, and an agent record lists the servers it connects to, but they answer different questions and need separate registers.

Is the public MCP Registry an MCP inventory?

No. The official MCP Registry at registry.modelcontextprotocol.io is a catalog of servers anyone in the world can publish, so it describes what exists to be installed, not what is installed. An enterprise MCP inventory records what is actually running in one organization: local stdio servers in dotfiles, remote vendor URLs, internal generated servers, and hosted connectors. The public registry is a useful source of candidates for the sanctioned list, and it says nothing about which of them your agents call.

How does an MCP inventory relate to shadow MCP?

Shadow MCP is the population of unsanctioned servers, cataloged as MCP09 in the OWASP MCP Top 10. Discovery surfaces those servers one finding at a time, and the MCP inventory is the register the findings land in, where each becomes a record with an owner and a disposition. The inventory also holds every sanctioned server, so it is the complete picture of the tool layer rather than only the alerts.

What fields should an MCP inventory record capture?

Each record should capture the server's identity (a URL for a remote server, a package specifier for a local one), its transport (stdio or remote), the tools it exposes with their read-only or destructive disposition, the credential it authenticates with and whose identity that credential carries, a human owner of record, the agents and clients allowed to connect, its sanctioned status, and when it was last seen serving a call.

What is an MCP inventory?

By Nolan Sullivan, Founding Growth Engineer

Published August 20, 2026

Definition

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 tools, where an agent inventory records principals.

MCP inventoryDefinitionSpeakeasy

An MCP inventory exists because nothing else in the security stack records the tool layer agents run on. An endpoint scan of an engineer’s laptop sees Cursor, an approved application on the software register. It does not see the GitHub Model Context Protocol (MCP) server wired into ~/.cursor/mcp.json, authenticated with a personal access token that can read and write every repository the engineer can. The scan records the harness and misses the server, the tools, and the credential behind them.

The public MCP Registry does not close the gap from the other side. It can tell you a GitHub server exists to be installed. It cannot tell you whether anyone in your organization installed it, which agents call it, or what it authenticates with. The Cloud Security Alliance’s April 2026 research note, The AI Agent Governance Gap: What CISOs Need Now, states the principle for agents: organizations cannot govern what they cannot see. The same reasoning applies one layer down, at the servers and tools those agents call, and vendors such as Obsidian Security now define an MCP server inventory in exactly those terms: server identity, connected agents, exposed tools, authentication state, and sanctioned status.

This page covers the tools half of that map. The principals half, the agents themselves, is the subject of what is an agent inventory.

Why can’t a CMDB or the public MCP Registry serve as an MCP inventory?

A CMDB and a software asset inventory record what is installed, and MCP servers mostly are not installed. A local stdio server is a few lines of JSON in a dotfile that tell an agent which package to execute. A remote server is a URL, and the only artifact on the endpoint is a runtime connection. Neither registers as software, so asset scans record the editor and miss everything it is connected to. The detection problem behind this is covered in depth in what is shadow AI.

The public MCP Registry fails for the opposite reason. It is a catalog of servers the world can publish: vendors and open-source maintainers list their servers there so clients and aggregators can discover them. That makes it a map of what exists, with no view of what any one organization runs. An enterprise MCP inventory is scoped to what is actually running here, which spans at least four populations:

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

A catalog that draws on the official registry is a useful source of candidates for the sanctioned list. The inventory is the record of which candidates were approved, what each one authenticates with, and whether agents are actually calling it.

What belongs in an MCP inventory record?

A list of server names is not an inventory. Each record needs the fields a security team will query when a credential leaks or a tool turns destructive:

Server identity. The URL for a remote server, or the package specifier and version for a local one. This is the key the rest of the record hangs on, so it has to survive renames and vendor migrations without orphaning history.
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, with the annotations the MCP specification defines: readOnlyHint marks a tool that only reads, and destructiveHint marks one that can delete or overwrite. A server whose tools are all read-only is a different review from one exposing create_refund, and tool lists change at runtime, so this field is a live feed rather than a one-time import.
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 whose identity the server presents upstream, because a shared credential makes every caller the same principal, the failure covered in what is NHI.
Human owner of record. The person who answers for the server, renews its review, and retires it. A server whose owner has left is a server nobody will notice misbehaving.
Connected agents. Which agents and clients are allowed to call the server. This field points into the principals register, the agent inventory, and each agent record points 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 row is a revocation candidate, and a busy row nobody sanctioned is the next investigation.

MCP inventory vs agent inventory vs shadow MCP: what’s the difference?

The agent inventory reference has the full three-way comparison. Seen from the tools side, the split is a question of what each register answers. The MCP inventory answers which servers expose a destructive tool and what each one authenticates with. The agent inventory answers which agents can touch billing and who owns each one. They are two halves of one map, principals on one side and tools on the other, and each record points at the other.

Shadow MCP is a population rather than a register: the unsanctioned servers, cataloged as MCP09 in the OWASP MCP Top 10, instances operating outside formal security governance. Discovery surfaces those servers one finding at a time, and the MCP inventory is where the findings land, each becoming a record with an owner and a disposition, alongside every server that was approved. How discovery works at the endpoint is covered in what is shadow AI, and what enforcement in front of the servers looks like is covered in what is an MCP gateway.

How does an MCP inventory stay current?

The failure mode is the same one that kills agent inventories: a spreadsheet compiled for an audit, accurate on the day it is finished and describing last quarter by the time anyone reads it. Wiring up a new server is a config-file edit, so 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, and 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, the tool, and the caller. Sanctioned servers register as a side effect of being used, and the last-seen field maintains itself from traffic instead of from a questionnaire.

What does a live MCP inventory unlock?

An allow-or-block posture becomes enforceable, because rules need a register to evaluate against: a call to a server with no row, or a row marked unsanctioned, can be blocked instead of logged. Least privilege lands at tool granularity, since the tools-and-disposition field is what lets a policy grant get_invoice without granting create_refund, one of the six controls in MCP security. Revocation stops being a hunt through laptop dotfiles, because when a server is compromised or rug-pulled, the row is where you turn it off. And when an assessor asks which servers agents can reach and what each authenticates with, the inventory is the evidence rather than a two-week scramble.

How does the Speakeasy AI Control Plane keep the MCP inventory live?

Everything above is architecture an organization could assemble itself. The Speakeasy AI Control Plane ships it as one system, and it maintains the MCP inventory as a side effect of how servers are brought in and called:

The gateway is the register of sanctioned servers. Servers enter the MCP gateway by being generated from the OpenAPI documents the organization already has, by being added remote by URL so an existing vendor server gets a governed endpoint in front of it, or by import from a catalog powered by the official MCP Registry. The catalog entry is the source; the gateway row, with its tools, credential, owner, and traffic, is 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, and enforcement fails closed when a rule cannot be evaluated.
Identity and credentials sit on the gateway. Upstream auth is provisioned per server, whether one-click OAuth on the user’s own identity, a managed credential stored once and never handled by users, or header pass-through. Each inventory row carries a named owner and a known auth method instead of a mystery secret in a dotfile.

Kept this way, the MCP inventory is a view over live traffic rather than a document that was true once. To see the inventory the platform maintains for the servers your agents already call, talk to us.