Audit an MCP Server Before You Install It

Direct answer: review four boundaries, not one tool list

Before installing or connecting an MCP server, create one review row per tool: its declared parameters, every system it could read or write under the proposed credentials, the host's invocation and confirmation rules, and the untrusted content that could influence its arguments. Record an approve, restrict or refuse decision before granting access. Treat unknown reach as an unresolved approval condition, not as zero reach.

This is a documentation-based walkthrough. Account-level steps were not exercised by the publisher; no server was installed or exercised. The checklist and decision rules are our recommended review method, not a penetration test or certification of an implementation.

Source-check date: 23 September 2026, using the supplied retrievals. This review uses the MCP tools specification at the 2025-06-18 URL, security guidance at the 2025-11-25 URL and OpenAI's Responses API guide. Treat those URL version labels separately from the retrieval date; this review does not establish a newly announced change.

Our interpretation: a declared tool description is a vendor statement, not a capability proof. Keep the four boundaries separate even when a vendor presents them as one feature.

1. Obtain the complete inventory without production access

The MCP tools specification documents tools/list as a paginated discovery operation. Tool discovery

The specification defines inputSchema as JSON Schema describing expected parameters. Tool definitions

1. Request an inventory exported from the maintainer's review environment, or inspect the proposed release's tool definitions without executing it. Record the package or endpoint, release or commit, operator, intended identity and export date.
2. For an exported tools/list result, require every page and record which identity and permissions produced it. Treat a static catalogue as declared evidence, not proof of what your eventual connection will expose.
3. Copy every parameter, including required and optional fields, defaults, enums, nested objects, referenced schema definitions and whether additional properties are permitted. Highlight unrestricted strings, arbitrary JSON, URLs, paths, queries, recipients, tenant selectors and resource IDs.
4. Record output descriptions and annotations separately from enforcement evidence. Ask what rejects an out-of-bound request and where that rejection is implemented.
5. If discovery requires running unfamiliar code or granting broad access, stop this pre-install review. Request an offline artifact or authorize a separate isolated evaluation without production credentials. Do not silently turn inventory collection into production installation.

The specification requires clients to treat tool annotations as untrusted unless they come from trusted servers. Annotation trust rule

Our review rule: do not accept a read-only annotation, reassuring name or narrow example as proof that broader operations are impossible.

The specification says resource links returned by tools are not guaranteed to appear in resources/list results. Resource links

Include returned links and embedded content in the review. Ask what the host may fetch next, under which identity, and whether that destination has been approved.

2. Map entitlement, handler reach and runtime reach

The MCP security guidance recommends a progressive, least-privilege scope model beginning with low-risk discovery or read operations. Scope minimization

For each tool, request a trace from argument to handler to downstream operation. Complete the following worksheet using implementation evidence, deployment configuration and permission exports. Mark unsupported answers as unknown.

Our interpretation: if a read handler uses a credential with write permission, record both facts rather than calling the entire installation read-only. Conversely, do not assert that a specific write is reachable through that handler without evidence of a route. Do not accept a prompt instruction as the sole access restriction.

Review local execution separately

The MCP security guidance recommends sandboxed local execution and restricted access to the filesystem, network and other system resources. Local-server controls

Before execution, review the exact startup command and package provenance. Record the process user, inherited environment, mounted directories, accessible credentials, outbound destinations and ability to spawn other processes. Do not approve local execution merely because the declared tools look narrow.

Review remote discovery separately

The MCP security guidance identifies SSRF risks during OAuth metadata discovery when a malicious server controls URLs fetched by the client. OAuth discovery and SSRF

Request the host owner's evidence of discovery-time destination checks, redirect validation and egress restrictions. Include the client's network boundary, not only the remote server's permissions. Make permission to connect for discovery a separate approval from permission to invoke business tools.

3. Establish who can steer calls and who must confirm

The MCP tools specification describes tools as model-controlled but does not mandate a particular user interaction model. Interaction model

The specification recommends confirmation for sensitive operations and showing tool inputs before calling the server. Client security considerations

OpenAI's Responses API guide documents approval by default before data is shared with a connector or remote MCP server. OpenAI approvals

The guide documents allowed_tools for importing only a selected subset of a server's tools. Tool filtering

It also documents require_approval set to 'never' as a way to skip approvals for all tools in that remote MCP server. Approval overrides

Our interpretation: these describe different layers, not interchangeable guarantees or a contradiction. For a Responses API deployment, record both allowed_tools and require_approval, including per-tool exceptions. For another host, request equivalent evidence rather than assuming OpenAI's default applies. Inspect whether the application presents approval requests to a person or accepts them automatically. Require the exact proposed arguments, target resource and destination to be visible before sensitive calls.

OpenAI documents deferred loading in which the model can use a server's label and description to decide when to search it, while individual function definitions load only when needed. Deferred loading

Our review rule: include deferred tools in the complete inventory. An unloaded or unobserved tool is not a denied tool; request the policy preventing later import or invocation.

OpenAI warns that malicious MCP servers may include hidden instructions designed to make models behave unexpectedly. Prompt-injection warning

For each tool, perform this paper trace rather than trying to predict whether a model will obey an attacker:

Untrusted author → content entering model context → proposed tool and arguments
→ reachable read, mutation or recipient → enforcing control → decision

• Mark free-text influence as yes, no or unknown, naming the parameter path, such as fields.body. Ask whether a retrieved document could influence the text sent there.
• Include ticket comments, documents, attachments, server descriptions and returned links. Name who can author or replace each input.
• For search parameters, ask whether internal context could be copied into a query sent to the server. For write bodies, identify where the text would be published.
• Trace IDs, enums and booleans too. Do not exclude target selection or visibility changes just because they are not prose.
• Name everyone with steering authority: server maintainers, deployment administrators, credential owners, host-policy editors, approvers, content authors and downstream permission administrators. Record change and revocation authority.

Record each attacker-controlled path as a possibility to assess, not an observed exploit. The approval question is which enforcing boundary would stop the proposed call if the model followed the untrusted instruction.

4. Worked example: a hypothetical ticket-system server

Everything in this example is hypothetical: tool names, permissions, host configuration and downstream behavior. Assume the proposed server exposes two tools using one account with tenant-wide ticket read/write permission. Both tools are available without confirmation. Tickets may be customer-visible, and updates may notify watchers or trigger configured webhooks. The intended workflow needs only to summarize internal OPS tickets and draft internal notes.

Hypothetical abuse path: an internal ticket comment asks the agent to copy a confidential summary into the public body of another ticket. That path would require the model to follow the instruction, select the write tool and supply the relevant arguments. The table identifies the route and blast radius; it does not establish that any model would take it or that a real server is vulnerable.

A narrower proposal to review

Our recommended redesign is to remove update_ticket. If the purpose is only drafting, keep the draft in the host for review and grant no ticket-system write. If posting internal notes is genuinely required, use the following requirements for a hypothetical replacement.

Record the overall decision as RESTRICT: do not install the original proposal; reconsider only after the narrower evidence is supplied. Do not treat filtering out the broad write tool as a substitute for narrowing credential and runtime reach. The replacement still accepts free text; do not describe it as injection-proof.

5. Keep authorization consent separate from tool confirmation

The MCP security guidance requires proxy servers to implement per-client consent to prevent the confused-deputy attack it describes. Confused-deputy guidance

For a proxy using a shared upstream OAuth client identity, request evidence of per-client consent, exact registered redirect-URI validation and state validation. Record who approves upstream scopes and how consent is bound to the requesting client. Keep this separate from confirmation of an individual tool call.

The MCP security guidance says servers must not accept tokens that were not explicitly issued for the MCP server. Token-passthrough guidance

Request a token-flow diagram identifying each token's issuer, audience, recipient and validation point, including separate downstream credentials. These confused-deputy and token-passthrough concerns come from MCP's own security guidance, not an allegation about any named product.

OpenAI's legacy-connector instructions say to supply an OAuth access token in the authorization field and handle OAuth client registration and authorization separately in the application. Connector authorization

Our interpretation: that integration instruction does not settle token-audience or downstream-validation questions. Hold any assertion that a particular connector's flow complies with, or violates, the MCP rule pending implementation evidence. Do not infer forbidden passthrough merely from the presence of an authorization field.

If an implementation guide explicitly contradicts the applicable specification, record both passages, versions and the affected configuration. State the disagreement and hold the affected assertion and approval condition instead of silently reconciling them. Do not mistake a protocol recommendation and a host-specific default for conflicting statements about the same layer.

6. Sign the decision and define when it expires

Use these editorial decision rules before installation:

• APPROVE: the complete inventory, effective entitlement, runtime reach, destinations, invocation policy and residual influence risks have documented boundaries acceptable to the accountable owner. Limit approval to the recorded configuration.
• RESTRICT: the purpose is acceptable only with named enforceable limits. List required changes and evidence; do not install the unrestricted configuration while waiting.
• REFUSE: proposed reach is unacceptable, necessary controls are unavailable, or evidence is insufficient to bound sensitive access. Distinguish demonstrated overreach from missing evidence.

Decision: APPROVE / RESTRICT / REFUSE
Purpose and permitted data:
Server operator, endpoint or package, version or digest:
Host version and effective configuration:
Complete tool inventory and schema artifact:
Credential identity, scopes and resource permissions:
Handler reach, runtime reach and downstream destinations:
Per-tool confirmation and content-influence review:
Evidence references and unresolved assertions:
Required restrictions and accountable owners:
Residual risk accepted by:
Decision date, next review date and revocation owner:

Our evidence rule: a tool that was never invoked in an evaluation is not a tool proven impossible to invoke. Require enforcement evidence, not just an absence of calls. This pre-install review cannot establish runtime correctness, uncover every hidden behavior or prove resistance to adversarial content.

OpenAI warns that MCP servers may update tool behavior unexpectedly. Server-change warning

Maintenance rule for this canonical guide: recheck the versioned specification, security guidance and implementation guide weekly; next review due 30 September 2026. A source change triggers review of affected assertions in this same guide, never a dated news page. Preserve supported explanations when nothing substantive changes. Reopen an installation decision after changes to server code, schemas, credentials, host policy or downstream destinations. If a required source cannot be retrieved reliably, leave that review unresolved rather than treating retrieval failure as confirmation.

Sources

• MCP Security Best Practices — supplied 2025-11-25 path
• MCP Tools specification — 2025-06-18
• OpenAI Responses API MCP guide — original approved URL