MCP Audit

Audit an MCP server against the current released MCP specification and any repo-specific compatibility constraints.

Read references/spec-baseline.md and references/checklist.md before making changes. Use references/version-watchpoints.md when spec drift, draft features, or older protocol targets may matter. references/common-findings.md captures recurring failure patterns. SOURCES.md is provenance, not the audit checklist.

Workflow

1. Pin the protocol baseline.

• Default to the latest released MCP spec revision unless the repo explicitly targets another version.
• Treat draft and SEP content as watchpoints, not release-blocking requirements, unless the user or repo explicitly asks for draft compatibility.
• Identify which MCP primitives and utilities the server actually implements: prompts, resources, tools, completions, logging, tasks, or experimental extensions.

1. Audit lifecycle and capability negotiation.

• Verify initialize and notifications/initialized behavior, negotiated protocol version, and claimed capabilities.
• Check that the server only advertises capabilities and sub-capabilities it actually supports, such as listChanged, subscribe, or task-related capability blocks.
• For HTTP transports, verify behavior around MCP-Protocol-Version after initialization if the repo owns transport handling directly.

1. Audit tools if present.

• Verify tools/list pagination, notifications/tools/list_changed if claimed, and client-visible metadata from the exported server surface.
• Check tool definitions: name, title, description, icons, inputSchema, outputSchema, annotations, and execution.taskSupport.
• Check tool result semantics: content, structuredContent, isError, embedded resources, resource links, and the split between protocol errors and tool execution errors.
• Review safety hints conservatively: readOnlyHint, destructiveHint, idempotentHint, and openWorldHint.
• Build the explicit upstream-mutation inventory for write-capable tools.

1. Audit prompts and resources if present.

• Prompts: capability declaration, prompts/list pagination, prompts/get, notifications/prompts/list_changed, argument handling, and prompt message content types.
• Resources: capability declaration, resources/list pagination, resources/read, resources/templates/list, resources/subscribe, notifications/resources/list_changed, notifications/resources/updated, URI scheme usage, MIME types, and text/blob encoding.
• Preserve the spec control hierarchy: prompts are user-controlled, resources are application-controlled, and tools are model-controlled.

1. Audit transports, auth, and security.

• stdio: newline-delimited JSON-RPC over stdin and stdout, no non-protocol stdout, stderr-only logging, and environment-based credential handling rather than HTTP OAuth flows.
• HTTP/Streamable HTTP: origin validation, localhost-binding guidance for local deployments, session and protocol-version handling, and HTTP-only auth flows when the server actually supports HTTP.
• Authorization: protected resource metadata discovery, WWW-Authenticate challenges, scope guidance, resource indicators, bearer-token handling, audience validation, and no query-string tokens.
• Security: input and URI validation, access controls, output sanitization, rate limits and timeouts, consent or sandbox expectations for local servers, and DNS-rebinding or SSRF risk surfaces.

1. Audit version and compatibility drift.

• Separate true spec violations from intentional older-version targeting or host-specific behavior.
• Check newer released-spec features that may be missing or mis-modeled, such as icons, tool name guidance, execution or task support, and structured tool output.
• Note draft-only or SEP-only expectations separately so the audit does not over-enforce unreleased behavior.
• Check repo-specific compatibility constraints such as tool-count limits, generated definitions, inspector or SDK quirks, and Warden rules.

1. Run validation.

• Prefer existing integration tests against the exported server surface.
• If none exist, add or update the narrowest automated check that proves the claimed protocol behavior.
• Refresh generated definitions or catalogs if the repo uses them.
• Finish with the repo's normal validation commands when appropriate.

1. Report the result.

• State the protocol baseline audited.
• List every primitive and capability the server implements.
• List every upstream-mutating tool.
• Separate confirmed violations, compatibility risks, and watchpoints.
• Call out what was validated via source inspection versus real server behavior.
• Note any assumptions about older spec targets, client quirks, or host-specific extensions.

Failure Handling

• If the repo targets an older MCP revision, audit against that version first and record the delta to latest separately.
• If framework adapters transform schemas or annotations, trust the exported wire surface over local declarations.
• If HTTP auth or transport behavior is owned by upstream infrastructure, audit the repo-owned boundary and explicitly mark the remainder as inherited or out of scope.
• If a requirement appears only in a draft or SEP, do not fail the server on it unless the user asked for draft compatibility.
• If a check passes structurally but the real server response differs, treat the wire behavior as authoritative.