Most organisations that use AI agents cannot list the MCP servers those agents connect to, which credentials each server holds, or what data a single tool call can reach. This template gives [Organisation] a register for every Model Context Protocol (MCP) server in use: local servers launched by developer tools, remote servers run by third parties, internal servers your teams build, and servers reached through a gateway. Each record captures the owner, the clients that connect, the transport, how the server authenticates, the tools it exposes and the systems and data those tools touch. It is written for AI platform, security architecture and identity teams, and for auditors who need evidence that agent tooling is governed. How to find shadow servers is covered in the Unsanctioned AI Agents and MCP Servers Guide, and the approval decision itself in the MCP Gateway and MCP Server Governance Guide. This register is where both end up.
How to use this template
- One record per server instance, not per product: the same open-source server run locally by 40 developers with personal tokens is one record with a deployment count, but the same server deployed centrally with a shared service credential is a separate record, because its credentials and blast radius differ.
- Required and Recommended: fields marked Required are the minimum for audit evidence and incident response. Recommended fields make the register useful for risk reduction. Start with Required and add the rest as discovery matures.
- Use fixed values: give every field with a closed list (transport, auth method, risk tier, status) a drop-down so you can filter and count. Free text is for descriptions only.
- Never store secrets here: record where a token or key is held and who can retrieve it, never the value. The register itself is a map of agent reach into your data: restrict it to [AI platform team], [Security team] and auditors, and log access.
- Tie it to the AI register: agents and AI systems are recorded in the AI Register and AI Inventory Template and the AI agent registry. Use the Server ID from this register as the linking key in those records.
- Replace bracketed text: [Organisation], [Gateway], [Secrets manager] and similar placeholders take your own values. Review periods in brackets are NHI Mgmt Group suggestions; set your own in policy.
1. Purpose
1.1 This register records every MCP server that an AI client, agent or automated workflow at [Organisation] is permitted to use, or has been found using, so that each server has an accountable owner, a known authentication model, a documented tool surface and data reach, and a review history.
1.2 It is the authoritative list used to configure client allowlists and the [Gateway], to scope credentials, to investigate incidents involving agent actions and to evidence inventory and least functionality controls: NIST SP 800-53 Rev. 5 CM-8 System Component Inventory and CM-7 Least Functionality, and NIST CSF 2.0 ID.AM-02 (inventories of software, services and systems) and ID.AM-03 (authorised network communication and data flows).
2. Scope and server types
2.1 A server is in scope if any MCP client used for [Organisation] work connects to it, whether on a managed endpoint, a CI runner, a hosted agent platform or a server-side application. The MCP specification defines two standard transports: stdio, where the client launches the server as a local subprocess, and Streamable HTTP, where the server runs as an independent process with an HTTP endpoint. Record both.
| Server type | Typical example | Where to discover it | Special handling |
|---|---|---|---|
| Local stdio server | A filesystem, Git or database server started by an IDE or desktop agent from an npm, PyPI or container package | MCP client configuration files on endpoints, EDR process telemetry | Record launch command and pinned version; runs with the user's privileges |
| Local HTTP server | A server listening on localhost for several local clients | Endpoint listening-port inventory | Record bind address; the spec says local servers should bind to 127.0.0.1, not all interfaces |
| Internal remote server | A server your team built to expose an internal API or data store | Code repositories, service catalogue, [Gateway] configuration | Full Section 6 and 7 fields; owner is the building team |
| Third-party remote server | A SaaS provider's hosted MCP endpoint | Proxy and egress logs, OAuth consent grants in the identity provider | Link the supplier record; the provider runs the server, you own the grant |
| Gateway-fronted server | Any server reached only through [Gateway] | [Gateway] routing table | Record both the gateway route and the upstream server |
| Discovered, not approved | Any of the above found by discovery without an approval record | Reconciliation (Section 9) | Status "Under review"; owner assigned within [10] working days |
2.2 Out of scope: the AI models and agents themselves (recorded in the AI register) and ordinary APIs that agents call without MCP (recorded in the [API inventory]). Where an agent reaches an API both directly and through an MCP server, record both paths.
3. Roles and responsibilities
| Role | Responsibility for this register |
|---|---|
| Register owner [AI platform lead] | Keeps the register current, runs reconciliation, reports metrics |
| Server owner | Accountable for one server record: accuracy, credentials, tool changes, review sign-off |
| Data owner | Approves the data reach recorded in Section 7 for systems they own |
| Identity and access team | Issues and scopes the credentials in Section 6; confirms OAuth client and consent records |
| Security architecture | Sets risk tier, approves exceptions, reviews high-tier servers |
| Procurement or supplier management | Links third-party servers to supplier due diligence |
4. Core identification fields
| Field | Guidance | Status |
|---|---|---|
| Server ID | [MCP-0001]; never reused | Required |
| Server name | Display name and, where published, the registry name in reverse DNS form (for example io.github.owner/server-name) | Required |
| Server type | Drop-down from Section 2 | Required |
| Purpose | One sentence: the business task it enables | Required |
| Server owner and deputy | Named people, not a team mailbox | Required |
| Publisher or supplier | Internal team, vendor or open-source maintainer; link the supplier record for third parties | Required |
| Source of the code or package | Package name and registry (npm, PyPI, container registry), repository URL or vendor endpoint | Required |
| Approved version | Exact pinned version or image digest; "latest" is not an acceptable value | Required |
| MCP protocol version | Version negotiated, for example 2025-11-25 | Recommended |
| Approval reference | ID of the approval request and decision date | Required |
| Status | Under review, Approved, Approved with conditions, Blocked, Retired | Required |
4.1 Pin versions. A malicious change can arrive in a routine update: in the postmark-mcp malicious MCP server case, the first 15 versions behaved as advertised and version 1.0.16 added a hidden blind copy of every outgoing email. A register that records the approved version makes an unreviewed upgrade visible.
5. Deployment and client fields
| Field | Guidance | Status |
|---|---|---|
| Transport | stdio, Streamable HTTP, legacy HTTP+SSE, custom | Required |
| Endpoint or launch command | Canonical HTTPS URL for remote servers; full launch command and arguments for stdio servers | Required |
| Hosting location | Endpoint, CI runner, [cloud account or cluster], supplier-hosted | Required |
| Bind address (local HTTP) | 127.0.0.1 expected; record any exception | Required for local HTTP |
| Origin header validation (HTTP) | Yes or No; the spec requires HTTP servers to validate Origin to prevent DNS rebinding | Recommended |
| Approved clients | Which MCP clients and agents may connect (IDE agent, desktop assistant, hosted agent platform, internal application) | Required |
| Deployment count | Number of endpoints or instances, from discovery | Recommended |
| Sandboxing | Container, restricted user, filesystem scope, network egress limits, none | Recommended |
| Gateway route | [Gateway] route ID, or "direct" | Required |
| Logging | Where tool calls are logged (client, gateway, server) and retention | Required |
6. Authentication and credential fields
6.1 Two credential relationships exist for most servers and both belong in the register: how clients authenticate to the server (inbound), and what the server uses to reach downstream systems (outbound). The MCP authorization specification applies to HTTP transports; stdio servers are expected to take credentials from the environment instead, which usually means a token in a configuration file or environment variable.
| Field | Guidance | Status |
|---|---|---|
| Inbound authentication | None, OAuth 2.1 per MCP authorization spec, API key, mTLS, gateway-enforced, OS-level (stdio) | Required |
| Authorization server | Issuer URL listed in the server's protected resource metadata (RFC 9728) | Required for OAuth |
| Client registration method | Pre-registered, Client ID Metadata Document, Dynamic Client Registration (RFC 7591) | Recommended |
| Token audience validation | Confirmed Yes or No: the server accepts only tokens issued for its own canonical URI (RFC 8707 resource indicator) | Required for OAuth |
| Token passthrough | Confirmed No: the spec forbids passing a client's token to downstream APIs | Required |
| Scopes granted | Exact scopes, and whether any are wildcard or omnibus | Required |
| Outbound credential type | Per-user OAuth token, shared service account, API key, cloud workload identity, personal access token | Required |
| Outbound credential location | [Secrets manager] path, OS keychain, environment variable, configuration file | Required |
| Credential owner and NHI record | Link to the service account or secret record in the NHI inventory | Required |
| Rotation and expiry | Last rotated, next due, maximum lifetime | Required |
| Acts as | The end user (delegated) or itself (service identity) | Required |
6.2 A server that uses one shared outbound credential for every user turns a per-user permission model into a single high-privilege identity. Record it as such and rate it accordingly in Section 8. Credential storage patterns are covered in the Local MCP Server Security Guide.
7. Tool surface and data reach fields
7.1 The register records what the server can do, not only what it is for. Capture the tool list from a tools/list response against the approved version and keep it with the record.
| Field | Guidance | Status |
|---|---|---|
| Tool list snapshot | Tool names and descriptions from tools/list, dated, with a hash of the definitions | Required |
| Dynamic tool changes | Whether the server declares listChanged and can alter its tools at runtime | Recommended |
| Write or destructive tools | Which tools create, change, delete, send or pay; do not rely on the server's own annotations, which the spec says clients must treat as untrusted unless the server is trusted | Required |
| Resources and prompts exposed | Yes or No, with a short list | Recommended |
| Downstream systems | Every system, API or data store the server reaches | Required |
| Data classification reached | Highest classification readable and writable | Required |
| Personal data | Yes or No; link to the record of processing where Yes | Required |
| External egress | Can tool output or input leave [Organisation]? To where? | Required |
| Human confirmation | Which tools require user confirmation in the approved clients | Recommended |
| Data owner sign-off | Name and date | Required for Tier 1 |
8. Risk tier and review frequency
8.1 Assign each server a tier from the highest-scoring factor. The thresholds and periods below are NHI Mgmt Group suggestions; adjust them in policy.
| Tier | Any one of these applies | Review every | Minimum controls |
|---|---|---|---|
| Tier 1 | Write or destructive tools on production systems; restricted or personal data; shared high-privilege outbound credential; external egress of internal data | [3] months and on every version change | Gateway route, per-user delegated tokens where possible, confirmation on write tools, full tool-call logging |
| Tier 2 | Read access to internal or confidential data; third-party remote server | [6] months | Pinned version, scoped credential in [Secrets manager], logging |
| Tier 3 | Public data only, no write tools, no stored credentials | [12] months | Pinned version, owner, allowlisted |
8.2 Each review confirms the owner, re-captures the tool list and compares its hash with the stored one, confirms scopes and credential rotation, and records the result and reviewer.
9. Discovery and reconciliation
9.1 Reconcile the register against discovery sources every [month]. Each discovered server with no record is opened as "Under review"; each record with no matching discovery evidence for [90] days is checked and retired if unused.
- Endpoint configuration: MCP client configuration files collected by [EDR or MDM].
- Repositories: configuration files and server code committed to [code hosting].
- Network: proxy and egress logs for remote MCP endpoints.
- Identity provider: OAuth consent grants and client registrations that point at MCP servers.
- Gateway and agent platforms: routing tables and connector lists.
9.2 Record per run: servers discovered, new unregistered servers, version drift (deployed version differs from approved), tool-list drift (hash changed) and records retired.
10. Change and retirement
10.1 A server owner raises a change before upgrading the version, adding tools, adding downstream systems or widening scopes. Tier 1 changes need security architecture approval before deployment.
10.2 To retire a server: remove it from client allowlists and the [Gateway]; revoke inbound OAuth client registrations and consent grants; revoke or delete outbound credentials and update the NHI inventory; remove configuration from endpoints; set status to Retired with the date and evidence. Keep the record for [audit retention period]. Credential retirement steps are covered in the NHI Offboarding and Decommissioning Guide.
Implementation guidance
- Start with remote and credential-holding servers: list every server that holds a stored token or reaches production first. They carry most of the risk and are easiest to find through identity provider consent grants and secrets manager paths.
- Build from telemetry, not surveys: collect configuration files from endpoints and repositories rather than asking teams what they use. Surveys find the approved servers; telemetry finds the rest.
- Expect these first-run findings: personal access tokens in plain-text configuration files, servers launched from unpinned packages, local HTTP servers bound to all interfaces, and one server used with several people's credentials.
- Use the register to enforce: generate client allowlists and gateway routes from records with status Approved, so an unregistered server cannot connect. See the MCP Gateway and MCP Server Governance Guide.
- Metrics to report monthly: registered servers by tier; percentage with a named owner; percentage on the approved version; unregistered servers found and median days to resolve; Tier 1 servers using shared outbound credentials; reviews completed on time.
- Test before trusting: verify audience validation, Origin checks and tool behaviour against the record using the MCP Security Testing Guide and the MCP Server Security Checklist.
- Framework alignment: NIST SP 800-53 Rev. 5 CM-8, CM-8(1) Updates During Installation and Removal, CM-7 and SC-12; NIST CSF 2.0 ID.AM-02, ID.AM-03 and PR.AA-05.
- Key sources: Model Context Protocol: Authorization (2025-11-25); Model Context Protocol: Security Best Practices; Model Context Protocol: Transports; Model Context Protocol: Tools; Model Context Protocol: The MCP Registry; NIST SP 800-53 Rev. 5.
Related NHI Mgmt Group resources: MCP Security Guide · MCP server rollout playbook · MCP Server Trust Assessment · Local MCP Server Security Guide