What should you check before connecting a third-party MCP server?

An agent team finds a third-party MCP server that connects in minutes. Its setup page calls it read-only, while its authorization screen asks for broad account access. The useful question is not whether the connection succeeds. It is what this particular server can see and do with your credentials, where its data travels, and how you will stop it after a change or failure.

Use one admission record per server and deployment. The tool-calling contract specifies a single operation’s inputs and executor checks; the permission ladder assigns authority to an individual action. This review happens at the integration boundary, before either design is allowed to depend on a vendor’s claims. The workbench below gives you a fillable, copyable, and exportable intake record.

Identify the exact connection under review

Write down the business task, the smallest expected tool set, the owner, and the environment. Then record the remote endpoint or full local launch command, publisher, package version or build digest, transport, client version, and negotiated protocol version. A protocol revision tells you how messages are exchanged; it does not identify the vendor code that will run. Findings from one combination cannot be assumed to hold after either side changes. The 2026-07-28 MCP revision also differs from earlier revisions in its message flow, so capture what the client and server actually negotiated.

With stdio, the client launches a server subprocess. Review the exact command, arguments, source, update behavior, execution account, and inherited environment as you would for code installed on that machine. Avoid a startup path that silently fetches an unpinned package. A remote Streamable HTTP connection instead needs a verified endpoint and operator. A local HTTP endpoint needs its own checks: the server should bind locally, validate Origin, and use appropriate authentication. “It listens on localhost” is not proof that another process or webpage cannot reach it.

Inventory the capabilities seen by the intended identity

Call tools/list with the kind of account you intend to deploy, follow every page, and save a sanitized snapshot of names, descriptions, input schemas, any output schemas, and behavior annotations. The advertised set can differ by authorization and can change later. An administrator’s list does not establish what a service account or ordinary user will see. Give each discovered tool one disposition: needed and allowed, present but blocked, or a reason to reject the integration. Enforce an allowlist outside the model. Also record any resources, prompts, or requests for client-side capabilities such as sampling or elicitation that are actually negotiated and enabled.

Tool descriptions and annotations are statements from the server. The MCP specification says a client must treat annotations as untrusted unless the server is trusted. A read-only hint is therefore a claim to test with synthetic records, downstream state checks, and observed network destinations. Returned text is untrusted content too; use the prompt-injection regression method when a result tries to become an instruction.

The protocol can signal a changed tool list when the relevant capability and subscription are in use. That signal is a reason to fetch and compare the full list, not automatic permission for new tools. Recheck after installation, a credential change, a software upgrade, and reconnection. A renamed tool, wider input range, changed effect, or new tool should stay unavailable until its review is complete.

Separate the identity, grant, and downstream data path

MCP’s HTTP authorization flow is optional. Where it is used, inspect the scopes requested and actually granted, the token’s intended audience, and who approves a later scope increase. An MCP server is required to validate tokens issued for itself; passing a token meant for another resource through to a downstream API is prohibited. An initial flow may ask for the scopes the server advertises, so an OAuth dialog alone does not establish least privilege. If a call is denied for insufficient scope, a step-up request is a new access decision, not a prompt for the agent to approve by itself.

A stdio server normally receives credentials through its environment. Record where the secret is injected, which account issued it, its object or tenant reach, and who can rotate it. Never paste the secret into this site’s browser-saved workbench. In either transport, test that a synthetic record belonging to another tenant is denied. A caller-supplied account ID does not prove the caller owns that account. The data-boundary map can help decide which fields should never cross to this vendor at all.

Draw every hop of a proposed call: user input and arguments, client, MCP server, downstream API, telemetry or logs, tool response, and model context. For each hop, note the operator, destination, permitted fields, retention window, and deletion contact. A “read” can disclose the search phrase, record number, or shipping address to an outside operator. A local process may see files and environment variables that were never passed as tool arguments. Limit file access, network egress, and logs in the runtime itself; the sandbox trial supplies observable denial probes. The 2026-07-28 specification marks roots as deprecated; an older client’s directory hints are not a filesystem sandbox.

Run denial, failure, and exit probes

One successful call only proves that a path works. Keep evidence from four kinds of trials: a permitted synthetic request; a cross-tenant or out-of-scope request that must be denied; timeout, rate-limit, disconnect, and tool-error behavior; and a revocation trial that must prevent future calls. Do not treat a transport response alone as a business outcome. If a write might have taken effect before a timeout, query the target system before retrying and use the recovery runbook for an unknown result.

An exit drill should disable the server and its allowed tools in the client, stop a local process or connection, revoke the OAuth grant or rotate separate API credentials, cancel outstanding jobs, then verify that an old credential is rejected. Stopping future access does not erase information already received by a vendor; check its retention and deletion process separately. Review again when the package, endpoint, scopes, tool list, downstream operator, or purpose changes.

Admission decision	Evidence required
Allow a narrow set	Complete snapshot under the intended identity, explicit allowlist, bounded credentials and data flow, plus passing denial and exit probes.
Limit to a test environment	Synthetic data and isolated credentials only, with a named owner and date to close each gap; production calls remain disabled.
Do not connect yet	Tools or grants cannot be enumerated, data destinations are unexplained, cross-tenant access succeeds, revocation fails, or a consequential effect cannot be verified.

Example one: a parcel-status server asks for return authority

A retailer wants its support assistant to look up parcel progress. The remote server advertises get_tracking_status, but the same test identity also sees create_return_label; its consent screen requests shipments:*. The team completes tools/list pagination with the intended account, tests invented tracking numbers and an invented address, and asks the provider to explain each data destination. A tracking number assigned to a different merchant must be denied by the server, regardless of what the model says.

If the provider cannot supply a read-limited grant or the client cannot reliably block the return-label tool, the team leaves production disconnected. If the narrow grant and tenant-denial probe pass, it permits only status lookup. A later update that introduces a pickup tool starts a new review while that tool remains blocked. The admission decision concerns the server’s whole exposed surface, rather than rewriting the schema of one query tool.

Example two: a local caption indexer runs outside its intended folder

A video team wants to search captions that have already been published. The proposed server starts through a package manager under a staff member’s personal account, where it could read the home directory and reach the network. The team records the full launch command and pinned package version, runs it in an isolated environment with only the public caption directory mounted, omits personal API keys, and restricts outbound traffic to any destination the task can justify.

They use invented captions to test indexing, search, and an interruption halfway through an index build. After the interruption, a partial index must not be presented as a complete corpus; a file manifest or rebuild procedure provides the missing check. Their exit trial verifies that the client no longer starts the process and that any separate credential is invalid. If the server requires unrestricted home-directory access, the integration fails. Neither a directory hint nor a prompt saying “search captions only” replaces process-level controls.

Common questions

Does a readOnlyHint remove the need for testing?

No. It is server-supplied metadata. Check actual grants, reachable objects, outbound destinations, and authoritative external state. Keep the response in the same untrusted-data boundary as other retrieved material.

Is revoking OAuth enough to retire a server?

Check the client configuration, queued work, separate downstream keys, and a denied request using the old credential. Vendor-held copies need a separate retention or deletion record. A single-run trace review can help establish the last call that occurred before shutdown.

Boundary

This is a technical integration gate, not a vendor contract review, supply-chain audit, or privacy impact assessment. Protocol compatibility and one passing call do not prove continuing trust. Consequential actions still need their own execution permission, approval, and recovery rules. An approval for one server version, identity, and purpose does not transfer to another.