Estate management · procedure
MCP Server Inventory: Finding Every Server You Actually Run
Nobody sets out to run undocumented infrastructure. It happens because an MCP server is a config-file entry away, and config files are not an asset register.
The short answer
To inventory MCP servers, pull from six sources rather than asking: client configuration files, the identity provider’s token grants, egress logs, package manifests, the gateway’s connection log and the expense system. Record eleven fields per server — including owner, credential scope and mutating-tool count — and gate new servers behind an intake step, because a list built once decays within a fortnight. The discovery is a week. Keeping it true is the actual work.
Why the list is always wrong
Adding an MCP server takes one JSON object in a client configuration file. No ticket, no deployment, no network change, often no review — and from the model’s point of view, a new set of capabilities it will happily use. That is the entire mechanism behind shadow MCP, and it is not a discipline problem. It is what happens when the cost of adding capability drops below the cost of recording it.
The consequences arrive in a predictable order. First, nobody can answer what an agent can reach. Then a credential outlives the project that needed it. Then two teams solve the same problem with two servers holding two different scopes on the same system, and the weaker scope sets your real posture. By the time an auditor asks, the question is not what your policy says but what your estate does.
The fix is not a stricter policy. It is a discovery pass you can repeat, plus an intake point that makes the record a by-product of getting access rather than a chore that competes with it.
Six places to look
Asking teams what they run produces a list of what they remember. These six produce a list of what is running. Run all six; each one catches something the others miss.
Client configuration files
The highest-yield source by a distance. Search repositories and developer machines for MCP client config — the file that lists servers for Claude Desktop, an IDE agent or a bespoke client. Every entry is a server somebody is using, whatever the architecture diagram says.
Search for the config filenames and for the server-declaration keys, not just for a vendor name. Half of what you find will be pointed at localhost, which is its own finding.
Identity provider grants
Every server that authenticates properly has a client registration, a service principal or an issued token somewhere in your IdP. Export active grants and look for anything issued to an agent, an assistant or a name you do not recognise. Grants with no recent use are the ones to revoke first.
This source also finds servers whose owner has left the company, because the grant outlives the person.
Egress logs
A server that reaches a SaaS API leaves a trail. Filter outbound traffic for the API hosts your agents touch and work backwards to the process. Slow, but it is the only source that catches a server nobody registered and nobody authenticated.
Package manifests
Grep dependency files for MCP SDK packages and known server packages. A dependency is not proof of production use, but it is proof somebody built something, and that thing usually still runs somewhere.
The gateway connection log
If you already have an enforcement point, its connection log is the cleanest source you have — but it only sees servers that go through it, so treat it as ground truth for governed traffic and useless for the rest. The gap between it and the other five sources is your ungoverned surface, and quantifying that gap is worth doing explicitly.
Expense and vendor records
Hosted MCP services get paid for. Card statements, SaaS management tools and procurement records surface servers that never appeared in any technical source, usually purchased by a team that did not know it needed to tell anyone.
Eleven fields per entry
A list of names is not an inventory. These eleven are the fields that later decisions actually consume — entitlement design, risk scoring, incident response and audit evidence each need specific ones, and collecting them later means a second pass over every server.
| Field | Why it earns its place |
|---|---|
| Server name and endpoint | Identity of the thing. Include transport, because stdio and HTTP have different blast radii. |
| Owner (a person) | Not a team alias. Steps that need a decision need somebody who can make one. |
| First-party or third-party | Determines whether you can harden internals or only contain them. |
| Version, and whether pinned | An auto-updating third-party server changes what your model can do without review. |
| Tool count and tool names | The real ones, from a tools/list call — not the documented ones. |
| Mutating tool count | The single most predictive field. Read-only servers are a different risk category entirely. |
| Credential and its scope | What the credential can do on the backing system at its widest, not what the server intends to use it for. |
| Backing systems reached | Where the consequences land. Drives data-residency and PII questions. |
| Risk class | One of a small fixed set. See tool risk scoring for a scheme that survives contact with engineers. |
| Which agents may reach it | Empty is an answer, and usually the wrong one: it means everyone. |
| Last reviewed date | An inventory without dates cannot tell you which entries are fiction. |
Two fields do most of the work in practice. Mutating tool count separates the servers that can cause an incident from the ones that can only leak, and credential scope tells you how bad that incident gets. If you can only collect two fields this week, collect those.
What to do with a server nobody owns
Every discovery pass turns up servers with no owner. The instinct is to find one; the better first move is to establish whether it is load-bearing, because most are not.
- 01Check for calls in the last 30 days. A server with no traffic is a credential to revoke, not an ownership problem to solve.
- 02Revoke the credential before removing the server. Cheaper to reverse, and it surfaces the real user within a day if there is one.
- 03Give it a deadline, in writing, with a named default owner. The team that owns the backing system inherits it if nobody claims it. Unowned-in-perpetuity is a decision too, just an unstated one.
- 04If it is claimed, run intake properly rather than grandfathering it. Grandfathered entries are the ones that fail the next audit.
Built on this thinking
Discovery is a week; keeping the register true is a product
Barzel Central Gateway makes registration the access path: a server is registered with owner, risk class and credential scope before an agent can route to it, and the connection log stays authoritative because it is the only route. Twenty-five tools covering registry, policy, routing, approvals and evidence.
Keeping it true after week one
A list built by a discovery pass is accurate on the day it is finished and wrong within a fortnight. Three mechanisms keep it honest, in descending order of effectiveness.
Intake as the access path
The only mechanism that really works: registering the server is how you get the credential and the route. Recording becomes the fast path rather than the compliance path.
Automated re-discovery, monthly
Re-run sources 1, 2 and 5 on a schedule and diff against the register. What you care about is the delta, and the delta should be small enough to read.
Quarterly owner attestation
One email per owner listing their servers, tools and credential scopes, requiring a reply. It catches stale entries, and it produces the attestation record an auditor will ask for.
Do not build a dashboard first. A monthly diff in a text file that somebody reads beats a live dashboard nobody opens, and it is a two-hour build rather than a two-sprint one.
Four mistakes worth naming
Inventorying servers but not tools
The server is the deployment unit; the tool is the capability. Entitlement, risk and approval all operate at tool level, so a server-level list cannot drive any of them.
Trusting documentation over tools/list
Documented tool lists omit what was left in from development. Call the endpoint and read what it actually advertises.
Recording a team as owner
Teams do not make decisions; people do. A team alias in the owner field is a blank owner field with extra steps.
Treating the inventory as the goal
The inventory is an input. Its value is realised when it drives entitlement, risk class and intake — otherwise it is a spreadsheet that ages.
Frequently asked questions
How do you inventory MCP servers?
Pull from six sources rather than asking teams: client configuration files, identity provider token grants, egress logs, package manifests, the gateway connection log, and expense and vendor records. Each catches servers the others miss, and the gap between the gateway log and the rest is your ungoverned surface.
What is shadow MCP?
An MCP server in active use that no central record knows about — typically added to a developer’s client configuration file without review. It happens because adding a server costs one JSON object, which is less effort than recording it.
What fields should an MCP server inventory record?
Eleven: server name and endpoint, a named human owner, first-party or third-party, version and whether it is pinned, tool count and names, mutating tool count, the credential and its true scope, backing systems reached, risk class, which agents may reach it, and the last reviewed date.
Which inventory field matters most?
Mutating tool count, followed by credential scope. The first separates servers that can cause an incident from ones that can only leak; the second tells you how bad that incident gets. Collect those two before anything else.
How do you find MCP servers nobody registered?
Client configuration files and egress logs. Config files reveal what developers actually connected to, and egress logs catch servers that never authenticated through your identity provider at all.
What should you do with an MCP server that has no owner?
Check whether it has been called in the last 30 days. If not, revoke the credential rather than hunting for an owner. If it is in use, set a written deadline with a named default owner — usually the team that owns the backing system — and run proper intake rather than grandfathering it.
How often should an MCP inventory be refreshed?
Automated re-discovery monthly against the register, reading only the delta, plus a quarterly attestation where each owner confirms their servers, tools and credential scopes by reply. The reply is also the evidence an auditor will ask for.
Is an MCP server inventory the same as an MCP registry?
No. An inventory records what exists, including things you would rather did not. A registry records what is approved and routable. The inventory is the discovery output; the registry is the governance artefact built from it.
Sources and further reading
Inventory is the oldest control in security and the least glamorous; the sources below are the ones that state the requirement in general terms. The MCP-specific discovery techniques and the eleven-field record are our own, from operating five servers and reviewing others.
- 01 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
- 02 · MCP projectModel Context Protocol — official documentation ↗Primary source for protocol structure, transports and the shape of a tools/list response.
- 03 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 04 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 05 · OpenSSFSLSA — Supply-chain Levels for Software Artifacts ↗Provenance and reproducibility framing for third-party server intake.
- 06 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 07 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
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 the control plane, 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. There is a free tier, so the evaluation costs nothing but an afternoon.
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.