Review an MCP server before connecting your coding assistant

The distinction was unusually clear in September 2025. Postmark reported that an unofficial npm package impersonating its MCP integration added a backdoor in version 1.0.16, secretly copying emails to an external server. Postmark said it had not published that npm package and that its own service was unaffected. A familiar product name had not established the software's provenance. ^[1]

Approve the exact server, identity and capabilities your task needs—not the protocol name. An MCP connection can introduce executable software, external data and instructions that affect tool selection. A useful review establishes who operates the server, what it can reach, what information it sends elsewhere, and what happens when it changes.

For a hypothetical coding task, suppose you want an assistant to search an internal issue tracker and read relevant acceptance criteria. It needs selected issue data. It does not need the ability to delete projects, export every attachment or send messages to arbitrary recipients. Start the connection review with that task.

Verify what will run and who operates it

A local server and a remote endpoint need different evidence. For a local package, record its publisher, upstream repository, exact release, launch command, arguments and runtime identity. For a remote service, record the operator, endpoint, account and authorization service. A repository link in a directory listing does not prove that an installed package was built from that repository.

MCP's 2026-07-28 security guidance requires clients offering one-click local configuration to show the complete command and obtain explicit consent before executing it. It also recommends restricting the server's filesystem and network access. Those are implementation requirements and recommendations; the presence of a connection dialog does not demonstrate that your client applies all of them. ^[2]

For the issue-tracker example, inspect the local launcher's inherited environment and mounts before providing any credential. If the server is remote, ask which upstream services it calls and what request, result and log data it retains. These are proposed review questions. An unanswered question is a scope limit, not something to infer from an OAuth success screen.

Read the tool definitions before trusting the labels

MCP tools have names, descriptions, input schemas and optional behavior annotations. The specification explicitly treats annotations as untrusted unless they come from a trusted server. A readOnlyHint is descriptive metadata, not a database permission. ^[3]

Invariant Labs' April 2025 experiments demonstrated a related failure: malicious instructions in tool descriptions redirected an assistant's behavior, including its use of other connected tools. The report also described changing a tool description after initial approval. These are historical research demonstrations, not evidence that all current clients fail the same way. ^[4]

Our proposed review table separates the advertised interface from the authority behind it:

For our tracker, two narrowly scoped read operations may be sufficient. A generic command runner would require a much broader review even if its first demonstration merely searches an issue.

Follow authorization to the upstream resource

An OAuth login establishes a particular authorization relationship. It does not establish that every downstream action is appropriate. MCP's authorization specification requires a server to validate that a token was issued for that server; it prohibits passing the received client token unchanged to an upstream API. When the server authenticates to another service, that upstream access uses a separately issued token. ^[5]

For the hypothetical tracker, ask three concrete questions: which account appears in the service audit log, which projects that account can read, and whether the server can request broader scopes later. Record the approved scope names and resource identifiers without copying credentials. If the server's UI says “search” while the upstream identity can administer the organization, the wider authority remains relevant.

Transport configuration adds another boundary. The Streamable HTTP specification requires validation of incoming Origin headers and recommends localhost-only binding for local servers. It also recommends authentication. A process listening on your machine is not automatically accessible only to the intended assistant. ^[6]

These protocol checks cannot substitute for code or operator review. Correct token validation can still deliver data to a legitimately authenticated but overprivileged integration.

Test the connection with synthetic content

Our proposed trial creates a disposable project containing ordinary issues and one harmless test instruction requesting an out-of-scope action. Let the assistant answer a normal issue-search question. Inspect the actual tool arguments and results: did it stay within the approved project, and did it attempt an operation that the task never authorized?

Keep a denied-resource check separate from the model test. An intentionally narrow test account should fail to read a second disposable project at the service boundary. A model declining to request it demonstrates different behavior. Neither result alone establishes protection against every possible injection.

If a sensitive tool is necessary, verify that its approval view shows the operation, resource and destination clearly. MCP's tool specification recommends user confirmation for sensitive operations, showing inputs before execution, and recording tool use. Check the actual client behavior rather than assuming that a protocol recommendation is implemented. ^[3]

The useful evidence is a recorded request and observed outcome. A screenshot of “connected” confirms neither the permitted scope nor the refusal path.

In an August Reddit discussion, arbyyyyh described distributing a template repository for MCP integrations at their healthcare organization:

Every request gets audited, every response gets audited.

— arbyyyyh, 27 August 2026^{[7] [7]}

The organization, implementation and logs were not supplied for independent inspection. The account illustrates an operating practice to ask about; it establishes neither compliance nor successful prevention of an attack.

Re-review changes, then prove revocation

MCP supports notifications when an advertised tool list changes. Such a notification helps a client discover a change; it does not decide whether the new capability is acceptable. ^[3]

For the tracker, retain the reviewed tool definitions with the package revision or remote-service review date. A new write tool, changed destination, added scope or materially different description should reopen the decision. Pinning a local package helps identify the executable version; it cannot freeze the behavior of a remote service behind an unchanged URL.

Finish the trial by revoking the disposable credential and removing the connection. Confirm the original operation now fails and that a local server process has stopped where applicable. You are ready to approve a useful integration when you can name both its permitted task and the concrete way to withdraw its access.