Why MCP servers need tracking
The Model Context Protocol (MCP) defines a way for clients to connect to servers that expose capabilities such as tools and resources. Inventory the deployed server and its client relationships, rather than treating a package name or repository as the whole asset. A local test instance and a production deployment of the same server can have different owners, data reach, network exposure and permissions. The official MCP specification is versioned; record the version or revision you actually reviewed.
What to record
Record one row per server deployment or materially different trust boundary. A useful minimum is: inventory ID; deployment name and environment; operator and accountable owner; hosting location and transport; server package/source and pinned version or revision; connected clients; declared capabilities; exposed tool names and what each can do; resources or prompts where offered; data sources and reachable boundary; authentication method and permission scopes; credential reference (never the secret); human approval checkpoints; evidence location; last verified date; and unresolved questions.
For a tool-capable server, compare the declared tools and input descriptions with what the owner intended to expose. MCP's tools specification describes `tools/list` discovery and `tools/call` invocation and says client applications should provide a human ability to deny tool invocations. Treat server-provided annotations as untrusted unless the server is trusted. These are protocol details, not evidence that a particular deployment is safe. Review the official Tools specification and Security Best Practices.
Discovery steps
- Define scope: managed clients, environments, teams and approved configuration or deployment sources.
- Collect server references from authorised client configuration, package manifests, deployment records and service ownership records. A configuration reference is evidence of configuration, not proof that the server is running.
- Ask the system owner to verify the current process or endpoint, package revision, declared capabilities, client list and reachable data boundary using approved operational evidence.
- Compare the discovered fields with access controls and change records. Record mismatches and evidence dates; do not probe systems outside the approved scope.
- Reconcile stale configurations and duplicate names with owners. Keep both the observed source and the resolution so a later reviewer can retrace the decision.
For remote servers, separately verify the endpoint, identity and scopes through the organisation's authorised configuration and service-owner process. For local `stdio` servers, inspect managed client configuration and the launched executable or package revision. Neither method alone establishes every runtime fact; avoid recording tokens, private prompts or copied customer data.
Ownership
Name an operational owner who can attest to deployment and a business owner who can explain purpose, users and data. They may be the same person in a small team. Require the relevant owner to review changes to server revision, tools, scopes, clients, endpoint, transport or data sources. Track an accountable resolver and due date for unknowns, and record retirement evidence for both client configuration and server access.
As a practical security check, compare requested scopes with the stated workflow and retain a reference to the approved decision. MCP's security guidance warns against token passthrough, which it describes as accepting a client's token and passing it to a downstream API without validating that it was issued for the MCP server. This is a protocol security concern; inventory fields do not themselves validate an implementation.
Template
The following is a hypothetical example of a manually verified test deployment, not a discovered asset or a built-in site example:
| Inventory field | Illustrative value | Evidence or follow-up |
|---|---|---|
| Deployment ID / environment | research-files-test-02 / test | Owner-verified test deployment record |
| Owner / client | Research platform team / managed desktop client | Confirm current client configuration revision |
| Transport / source revision | Local stdio / pinned package revision not verified | Verify actual launched package version |
| Capability / data boundary | Hypothetical `find_document` read tool / public research corpus | Compare declared tool list and corpus mount with approved configuration |
| Authentication / permissions | No credential recorded here / read-only access claimed | Verify effective OS permissions; do not infer from the label |
| Review state | Owner review not recorded | Assign an owner and record the review date after checking evidence |
Duplicate a row for a production deployment if its owner, client, revision, reachable data or permissions differ. Keep credentials in an approved secret manager; this template stores references only. The site's inventory builder is a manual starter tool and does not discover MCP servers or validate their configuration.
Continue with the AI agent inventory builder, the AI inventory template, or the AI agent inventory template.
Sources: MCP specification (2025-11-25); MCP Tools; MCP Security Best Practices; NIST AI RMF 1.0.