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 CitedIndex; no server was installed or exercised. The checklist and decision rules below are our recommended review method, not a penetration test or a certification of any implementation.

Source-check date: 7 September 2026, using the supplied retrievals. The source baseline combines the MCP tools specification at the 2025-06-18 URL, security guidance at the 2025-11-25 URL, and OpenAI's implementation guide. Those version labels are not evidence of a newly announced change.

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

1. Obtain the inventory without granting production access

The MCP tools specification documents a paginated tools/list request for discovering available tools. MCP tool discovery

The specification defines inputSchema as JSON Schema for a tool's expected parameters. Tool definitions

1. Ask the maintainer for a complete, version-matched inventory exported from its review environment, or inspect the proposed release's tool definitions without executing it. Record the release or commit, endpoint, operator, intended identity and export date.
2. For an exported tools/list result, require every page, not just the first response. Record which identity and permissions produced the inventory. Mark a static catalogue as declared evidence rather than evidence of what your eventual connection will expose.
3. Copy every tool name and parameter, including required fields, optional fields, defaults, enums, nested objects and whether extra properties are allowed. Highlight unrestricted strings, arbitrary JSON objects, URLs, paths, queries, recipients, tenant selectors and resource IDs.
4. Record annotations and output descriptions separately from enforcement evidence. Ask what rejects a request outside the claimed boundary and where that rejection is implemented.
5. If a complete inventory is available only after executing 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 discovery into production installation.

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

As a review rule, do not treat a read-only annotation, reassuring name or narrow example as evidence that broader operations are impossible.

2. Map actual entitlement and runtime reach

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

For each tool, request a trace from argument to server handler to downstream operation. Use deployment configuration, implementation evidence and permission exports to fill in the following worksheet; mark unsupported answers as unknown.

• Identity: which user or service account supplies access, who can replace its credentials, and which issuer and intended audience apply?
• Reads: enumerate services, tenants, projects, tables, tickets, attachments, files and secret stores within reach. Record resource-level restrictions as well as scope names.
• Writes: enumerate create, edit, delete, permission changes, outbound messages and administrative operations. Include downstream automations, notifications or webhooks where applicable; request evidence rather than assuming they exist.
• Destinations: identify the MCP operator, upstream APIs, storage, logging and telemetry destinations. Record what inputs and outputs each receives, and ask about retention and residency.
• Enforcement: identify the credential restriction, server-side authorization check or runtime policy that enforces each limit. Do not accept a prompt instruction as the sole restriction.

For local MCP servers, the security guidance recommends sandboxing and restricted filesystem, network and other resource access. Local-server controls

Review the exact startup command and package provenance before execution. Record the process user, inherited environment, mounted directories, accessible credentials, outbound destinations and any privilege to spawn other processes. Keep this runtime worksheet separate from the tool worksheet: do not approve local execution merely because the declared tools look narrow.

The security guidance also identifies SSRF risks when MCP clients fetch OAuth metadata URLs supplied through a malicious server's discovery flow. OAuth discovery and SSRF

For a remote connection, ask the host owner to document discovery-time destination checks, redirect validation and egress restrictions. Include the client's network boundary in the review, not only the remote server's permissions.

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. User interaction model

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

The same 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

These are different layers, not interchangeable guarantees: use the protocol to understand the interaction model and the implementation guide to inspect the chosen host. For a Responses API deployment, record both allowed_tools and require_approval; for another host, require its equivalent evidence rather than assuming OpenAI's default applies. Inspect whether the application actually presents approval requests to a person or automatically accepts them. As a review requirement, show the proposed arguments, target resource and destination before sensitive calls.

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

Perform a paper trace for every free-text argument: untrusted source → text entering model context → proposed tool and arguments → reachable destination or mutation → enforcing control. Include ticket comments, retrieved documents and attachments in this trace. For a search query, ask whether internal context could be copied into the query; for a write body, ask who could influence the text and where it would be published. Also trace resource IDs and enums: do not exclude a parameter merely because it is not prose.

List control owners explicitly: who can update the server or its tool descriptions, change credentials, alter the host allowlist, approve a call, edit retrieved content, or change downstream permissions? Record each owner's change and revocation authority.

4. Worked example: a hypothetical ticket-system server

Everything in this example is hypothetical, including tool names, permissions, host settings and downstream behavior. Assume a proposed server exposes two tools, uses one account with tenant-wide ticket read/write permission, and is configured in a host with both tools available without confirmation. In this scenario, tickets may be customer-visible, and updates may notify watchers or trigger configured webhooks. The proposed workflow needs only to summarize internal tickets in project OPS and draft internal notes.

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

A narrower proposal to review

Our recommended redesign for this scenario is to remove update_ticket and replace it with a purpose-built internal-note operation. The following restrictions are requirements for the hypothetical replacement, not claims about an existing ticket product.

Record the overall decision as RESTRICT: no installation of the original proposal; consider approval only after the narrower evidence is supplied. Do not treat filtering out the broad write tool as a substitute for narrowing the credential or runtime. The replacement still contains a free-text write argument, so do not describe it as injection-proof.

5. Ask two separate authorization questions

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, registered redirect-URI validation and state validation. Record who approves the upstream scopes and how that consent is bound to the requesting client. Do not confuse this authorization consent with 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 the issuer, audience, recipient and validation point for each token, including any separate downstream credential. Attribute these confused-deputy and token-passthrough concerns to MCP's own security guidance; this review makes no allegation against a named product.

OpenAI's 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 instructions

That integration instruction does not settle the token-audience and downstream-validation questions in this review. Hold any assertion that a particular connector's token flow complies with, or violates, the MCP rule until implementation evidence resolves it. Do not infer forbidden passthrough merely from the presence of an authorization field. If the chosen implementation's documented requirements contradict the specification, record the exact disagreement and hold the affected assertion and approval condition rather than silently reconciling them.

6. Sign the decision and define when it expires

Use these editorial decision rules for the pre-install record:

• APPROVE: the proposed purpose, tool inventory, effective entitlement, destinations, invocation policy and residual content-influence risks have documented boundaries acceptable to the accountable owner. Approval applies only to the recorded configuration, not every future release.
• RESTRICT: the purpose is acceptable only with named enforceable limits. List each required change and its evidence; do not install the unrestricted configuration while waiting.
• REFUSE: the proposed reach is unacceptable, necessary controls are unavailable, or the operator cannot supply enough evidence to bound sensitive access. Record whether the reason is demonstrated overreach or 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:
Runtime, network and downstream destinations:
Per-tool approval 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:

As an evidence rule, a tool that was never invoked in an evaluation is not a tool proven impossible to invoke. Request enforcement evidence rather than treating absent calls as a boundary. 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 14 September 2026. A source change triggers review of the affected assertions in this same guide, not a dated news page. Preserve the baseline when nothing substantive changes. For each installation decision, also reopen review after changes to the server, schemas, credentials, host policy or downstream destinations. If a required source cannot be retrieved reliably, keep that review unresolved rather than treating a redirect failure as confirmation.

Sources

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