Most organisations approved their first Model Context Protocol (MCP) servers in a hurry, and few have measured since whether the estate still matches what was approved. This health check is a recurring review of the MCP servers your AI agents and developer tools already use: the registered remote servers, the local servers launched on laptops, the credentials those servers hold and the tool scopes they expose. It gives eight metrics with formulas and thresholds, a cadence, a findings log and a remediation map. It is for AI platform owners, security engineers and the people who sign off agent risk, and it answers the practical question of how to audit MCP servers once they are in production.
This page measures; it does not repeat the hardening steps. For the control list use the MCP Server Security Checklist, and for the design and governance model the MCP Gateway and MCP Server Governance Guide. The metrics are vendor-neutral and apply whether servers are reached directly, through a gateway or from a registry.
What this health check covers
The review covers every MCP server that an agent, an IDE assistant or an internal application in your organisation can connect to: remote servers reached over HTTP, local servers started over the stdio transport, and servers fronted by an MCP gateway. It also covers the credentials those servers use to reach downstream systems, because an MCP server is usually a non-human identity with access to something valuable, and the logs that show who called which tool.
- Who runs it: the AI platform or developer platform owner collects the data; the security team validates the endpoint discovery and credential metrics; the CISO or head of AI governance signs off.
- What it is not: a penetration test, a tool poisoning hunt or a code review of a single server. For those use the MCP Security Testing Guide and the MCP Server Trust Assessment, which decides whether a server should be approved in the first place.
- Questions it answers: "how many MCP servers do we really have", "which ones hold static tokens", "do our remote servers enforce OAuth" and "could we reconstruct what an agent did through a server last week".
Key takeaways
- The register is only as good as endpoint evidence. Measure approved servers against what is configured on developer machines and agent hosts, not against what teams declare.
- Credentials decide blast radius. Count servers that reach downstream systems with static tokens or keys, and track the trend down every quarter.
- Remote servers need real authorisation. The MCP authorisation specification builds on OAuth 2.1 for HTTP transports; measure how many remote servers accept unauthenticated or non-audience-bound requests.
- Tool scope drifts. Compare the tools and scopes each server exposes with the use case it was approved for, and treat the gap as over-permission.
- Pin and log, or you cannot investigate. Unpinned server versions and missing tool-call logs are the two findings that turn a small incident into an unknown one.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this MCP server health check at the cadence below. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare results quarter on quarter, because the trend in unapproved servers and static tokens tells you more than any single score. Replace the bracketed placeholders, such as [Organisation] and [Role], with your own names.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Endpoint scan for MCP client configurations | Monthly | Endpoint engineering | Security engineering lead | Scan output, count of servers per host, delta against the register |
| Credential review for servers with downstream access | Monthly | AI platform team | Identity and access lead | Credential type per server, age, storage location |
| Full metrics review (this page) | Quarterly | AI platform owner | CISO and head of AI governance | Metrics table, extracts, findings log, sign-off record |
| Tool scope recertification | Quarterly, and when a server adds tools | Server owner | AI governance board or delegate | Tool list snapshot, approved use case, decision per tool |
| Log reconstruction test | Twice a year | Security operations | AI platform owner | Test scenario, events found, gaps |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Registered server" means a server recorded in your MCP server register or inventory with an owner and an approval decision. "Remote server" means a server reached over an HTTP-based transport; "local server" means one launched on the same machine as the client, usually over stdio.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| MCP-01 | Registered servers | Distinct servers found in use (endpoint scans, gateway logs, egress logs) that are in the register with owner and approval ÷ distinct servers found in use | MCP server register, endpoint scan results, gateway and egress logs | 98% or above | 90% to below 98% | Below 90% |
| MCP-02 | Unapproved servers on endpoints | Managed endpoints with at least one MCP server configured that is not approved for that population ÷ managed endpoints with any MCP client configuration | Endpoint management inventory, file collection of MCP client configuration files | Below 2% | 2% to 10% | Above 10% |
| MCP-03 | Servers with static tokens | Registered servers that reach a downstream system using a long-lived API key, personal access token or password ÷ registered servers with downstream access | Server configuration, secrets manager records, secrets scanning of configuration files | Below 10%, each with a dated exception | 10% to 30% | Above 30%, or any static token stored in plain text |
| MCP-04 | Tool scope over-permissioned | Registered servers exposing at least one tool or downstream scope not needed for the approved use case ÷ registered servers reviewed | Tool list snapshots, downstream credential permission listings, approval records | Below 5% | 5% to 20% | Above 20% |
| MCP-05 | Servers with pinned versions | Server deployments and client configurations that reference an exact version or content digest ÷ all server deployments and configurations | Client configuration files, deployment manifests, container image references | 95% or above | 80% to below 95% | Below 80% |
| MCP-06 | Authentication enabled share | Registered servers (local and remote) that reject a request with no valid credential or session binding ÷ registered servers | Authentication test results, server configuration | 100% | 95% to below 100%, all gaps local stdio servers with documented exception | Below 95%, or any remote server reachable without authentication |
| MCP-07 | Remote servers without OAuth | Remote servers that do not publish protected resource metadata, do not validate token audience, or pass client tokens through to downstream APIs ÷ remote servers | Protected resource metadata checks, token validation tests, gateway configuration | 0% | Above 0% to 10%, each on a dated remediation plan | Above 10%, or any server found passing tokens through |
| MCP-08 | Log coverage | Registered servers whose tool calls are logged centrally with caller identity, tool name, timestamp and outcome, retained for at least 90 days ÷ registered servers | Central log platform, gateway logs, server log configuration | 95% or above | 80% to below 95% | Below 80% |
Why these eight
MCP-01 and MCP-02 measure whether you know what exists. MCP-03 and MCP-04 measure what a compromised or manipulated server could reach. MCP-05 measures whether what runs today is what was approved. MCP-06 and MCP-07 measure whether anyone can call the server. MCP-08 measures whether you could investigate. The thresholds are deliberately strict for remote servers, because a remote server is reachable by more callers than any local process.
The authorisation metrics follow the MCP specification. The 2025-06-18 authorisation page states that authorisation is optional for MCP implementations, that HTTP-based transports should conform to it, and that stdio implementations should instead retrieve credentials from the environment. Where it is implemented, MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), must validate that access tokens were issued for them as the intended audience, and must not pass through the token received from the client to upstream APIs. MCP-07 treats a remote server that fails any of these as a red result, because optional in the protocol does not mean optional in an enterprise. The specification is versioned by date, so confirm the current revision when you run the review.
How to collect the data
- Export the register. Start from your MCP server register with owner, approval date, approved use case, transport, version and downstream systems for each server. The MCP Server Inventory Template lists the fields. Without it, MCP-01 has no denominator to compare against.
- Scan endpoints. Use your endpoint management tooling to collect MCP client configuration files from managed laptops and agent hosts, then normalise each server entry to a name, command or URL, and version. The method is described in How to audit MCP servers on developer laptops. This feeds MCP-01, MCP-02 and MCP-05.
- Add network evidence. From egress proxy, firewall or DNS logs, list connections to known remote MCP endpoints, and from the gateway's logs list every upstream server it reaches. Servers that appear here but not in the register count against MCP-01. See the Unsanctioned AI Agents and MCP Servers Guide.
- Classify credentials. For each registered server with downstream access, record the credential type (static key or token, OAuth access token, workload identity, short-lived token from a secrets manager) and where it is stored. Run secrets scanning across collected configuration files. MCP Static Token Audit covers the patterns. This feeds MCP-03.
- Snapshot tools and scopes. Call the server's tool listing from a test client and store the result with a date. Compare it with the approved use case and with the downstream permissions held by the server's credential. Any extra write, delete, admin or wildcard capability counts for MCP-04.
- Test authentication. For each remote server, send a request with no token, with an expired token and with a token issued for a different resource. The server should return HTTP 401 in each case. Fetch the protected resource metadata document and confirm it lists an authorisation server. For local servers on HTTP, confirm they require a token or are bound to a restricted local channel. Record results for MCP-06 and MCP-07.
- Trace one session. Pick a recent agent session that used two or more servers and try to reconstruct it from central logs: caller identity, each tool called, parameters summary and outcome. If you cannot, the servers involved fail MCP-08.
Red flags that need action now
- A remote MCP server reachable from the internet that answers tool calls without any credential.
- A server forwarding the client's access token to a downstream API (token passthrough), which the MCP specification forbids.
- A static token with administrative scope on a source control, cloud or ticketing system, stored in plain text in a client configuration file.
- An MCP server configured on many endpoints that no one in the register owns, or whose package name resembles an approved one.
- A server configured to fetch "latest" on every start, in a team that handles production credentials.
- A tool list that changed since the last snapshot with no change record, especially new tools that write, delete or execute.
- No central record of tool calls for a server used by agents that run unattended.
- A local server listening on a network interface rather than stdio or a restricted local channel.
Unknown servers with downstream credentials, unexpected tool changes or tool calls that no user initiated may indicate compromise rather than drift. Contain first using the MCP Incident Response Playbook, then clean up.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-MCP-01 | [Description, population and figure, e.g. 14 of 120 servers found in use are not in the register] | MCP-01 | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-MCP-02 | [Description] | MCP-03 | [Severity] | [Role] | [Date] | [Status] |
| HC-MCP-03 | [Description] | [Metric ID] | [Severity] | [Role] | [Date] | [Status] |
Suggested due dates: red flags within 7 days, red metrics within 30 days, amber metrics within 90 days. Risk acceptance needs the AI platform owner's signature and an expiry date no longer than the next quarterly review.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Unregistered and unapproved servers (MCP-01, MCP-02) | MCP Gateway and MCP Server Governance Guide and Local MCP Server Security Guide |
| Static tokens and credential storage (MCP-03) | MCP Static Token Audit and Secrets Management Guide |
| Over-permissioned tools and scopes (MCP-04) | MCP Server Security Checklist and Least Privilege Techniques Guide |
| Unpinned versions and supply chain (MCP-05) | MCP Registry and Server Publishing Security Guide |
| Missing authentication and OAuth gaps (MCP-06, MCP-07) | MCP Authorisation Specification Guide and Remote MCP Server Hardening Guide |
| Log gaps (MCP-08) | MCP Gateway and MCP Server Governance Guide (logging section) and Agent Controls and Monitoring Guide |
Related guides
- MCP Server Security Checklist: the hardening controls this review measures.
- MCP Security Guide: the overview of MCP risks and architecture.
- MCP, Protocols & Agent Platforms Maturity Model: where these results place your programme.
- Top 10 MCP Security Risks: the risks behind each metric.
- MCP Incident Response Playbook: what to do when a red flag turns out to be an incident.
References
- Model Context Protocol: Authorization specification (2025-06-18)
- Model Context Protocol: Security Best Practices (token passthrough, session hijacking, local server compromise, scope minimisation)
- IETF: RFC 9728 OAuth 2.0 Protected Resource Metadata
- IETF: RFC 8707 Resource Indicators for OAuth 2.0
- OWASP: Non-Human Identities Top 10 2025 (NHI2 Secret Leakage, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets)
- NIST: SP 800-53 Rev. 5 (CM-8 System Component Inventory, IA-5 Authenticator Management, IA-9 Service Identification and Authentication, AC-6 Least Privilege, AU-12 Audit Record Generation)
- NIST: Cybersecurity Framework 2.0 (ID.AM-02 inventories of software and services, PR.AA-05 access permissions, PR.PS-04 log records)
Related NHI Mgmt Group resources: MCP Security Guide, MCP Server Inventory Template, MCP Security Scanners Guide, Agent Identity and Access Guide.