The MCP Server Inventory That Discovered Another MCP Server

SATIRE — At 9:03 a.m., the security team at fictional mid-market observability concern Pebblewhistle Systems asked a routine question: “How many MCP servers are running?” The room achieved the silence normally reserved for a production database migration whose owner has just said, “It should be fine.” Someone opened a spreadsheet called AI Tooling Final FINAL v7.xlsx. Someone else opened Slack. A third person opened an AI editor, which helpfully suggested installing an MCP server that could search Slack for the answer.

The number is definitely between zero and the building

The first answer was 14. This came from the Platform Enablement Guild, which defines “running” as “has a Kubernetes deployment owned by a team that remembers creating it.” The second answer was 63, from Developer Experience, which included every entry in managed editor settings. The third was 211, from Finance, which searched expense reports for the words “server,” “MCP,” and “unreasonably cheerful SaaS onboarding call.”

All three answers were technically defensible because nobody had agreed on the unit being counted. Is a local stdio process an MCP server? Is a copy of the same server in 37 developer home directories one server, 37 servers, or a lifestyle? Does a remote endpoint count if it is present in a configuration file but its token expired last spring? Does a server that exposes one tool named run_anything count as one server or as the beginning of an incident report?

The protocol is admirably clear that servers can expose tools, resources, and prompts, while the operational environment is admirably clear that each of these can arrive through a local process, a remote service, a desktop configuration, an editor extension, or a command a developer copied from a README at 11:47 p.m. The company had standardized neither discovery nor ownership, but it had standardized enthusiasm.

The emergency inventory procedure

Pebblewhistle formed a cross-functional task force: Security, IT, Platform, Legal, Procurement, and one staff engineer who had opened the ticket only to mute it. The task force produced a four-stage plan intended to deliver a trustworthy server count by the end of the quarter, or before the protocol changed enough that the question became embarrassing in a different way.

1. Search source repositories for mcpServers, stdio, streamableHttp, and suspiciously named packages such as company-memory-but-local.
2. Search fleet-management records for editor configuration directories, then accept that this finds only managed machines and none of the laptops named after houseplants.
3. Ask each developer to self-report their MCP servers in a form requiring a server name, transport, owner, data classes reachable, authentication method, and whether “I thought it was just a plugin” applies.
4. Compare the answers with network logs, secret-manager access, SSO application assignments, container workloads, and the folder called misc in the shared engineering drive. Do not open misc without a witness.

The technical portion started with the customary command, which discovers neither the whole truth nor peace:

rg -n --hidden --glob '!node_modules' \
  'mcpServers|modelcontextprotocol|stdio|streamable.?http' \
  ~/Library/Application\ Support ~/.config ~/src

Within 18 seconds, it found 49 configuration fragments, three examples, two abandoned experiments, a test fixture, and a README that instructed engineers to paste a long-lived production token into a local JSON file “for convenience.” The README had a green checkmark beside it, indicating it had passed review.

A server count is not a permission model

The resulting inventory had columns for endpoint, transport, package version, sponsoring team, tool names, credentials, reachable systems, log location, and last observed use. The crucial column was “effective authority,” because “GitHub MCP” is not a meaningful risk description. “Can create repository secrets in the production organization when invoked by an editor on an unmanaged laptop” is a risk description, although it has the unfortunate property of making meetings longer.

This is where Pebblewhistle discovered its favorite category: the server with no owner but several grateful users. One deployment had been created for a hack week by a team that no longer existed. It could read issue trackers, deploy previews, and a calendar named Executive Scheduling — Do Not Automate. Its service account was called mcp-helper. The account description said, “temporary.” The account was 418 days old, which in temporary-account years is pre-Cambrian.

The team proposed a formal registration gateway. Every remote server would receive an owner, an environment, a declared tool list, authentication requirements, data classifications, a retirement date, and telemetry. Every local server would at least receive an install source and a declaration of what executable launches it. The gateway would not make a server safe. It would merely stop the organization from discovering its own authority boundaries through folklore.

Controls, with the appropriate amount of inconvenience

The first control was not a magical “MCP security platform.” It was a policy: no production credential in a local MCP configuration, no anonymous remote endpoint with privileged tools, and no server allowed to present a broad capability because the tool author did not want to name the operations separately. The second was to use normal identity and authorization controls at the HTTP boundary for protected tools, rather than allowing a tool to discover, after it has begun doing work, that it should perhaps ask who is calling.

The third was logging that joins a tool call to a user, client, server, credential, target system, and outcome. This is boring, which is fortunate. An audit record that requires reconstructing the actor from terminal history, editor telemetry, a reverse proxy, and a message reading “yo did anyone run cleanup?” is not observability. It is interactive fiction.

The inventory project was eventually declared complete at 92 servers, plus 27 under investigation, plus 11 “not servers, according to their creators.” Security did not celebrate. It opened a recurring monthly review and asked for the same number again. This was considered unfair by engineers, who had already counted them once.

The joke is that the count will never stay still. The true observation is less funny: if a tool can reach code, tickets, cloud accounts, databases, or internal documents, then its ownership, credentials, and effective permissions are operational inventory—not optional metadata added after the demo works.