Review an MCP Server Before Enabling Writes

Test an MCP server's identity, permissions, tool changes and uncertain writes before allowing an AI application to change business records.

trigger="An AI application can discover an MCP server's tools, but the team has not established which changes it may safely execute." owner="The application owner accountable for the business records the integration can change." participants={['Integration engineer', 'Identity engineer', 'Security reviewer', 'Business record owner', 'Independent test observer']} prerequisites={['An isolated test environment with synthetic records', 'A named server operator and identified server release', 'A proposed tool and permission allowlist', 'Restricted evidence storage and a working connection stop control']} outputs={['A server and execution-boundary register', 'A tool-specific authority matrix', 'Denial and uncertain-write test evidence', 'A scoped acceptance decision with expiry and re-review triggers']} doneWhen={['Every enabled tool has a tested business boundary', 'Unauthorized fixtures are denied without side effects', 'Changed inputs invalidate prior approval', 'Uncertain writes have a demonstrated reconciliation path', 'Unsupported tools remain disabled and the release owner signs the evidence']} />

Decide which changes the integration may make

Use this playbook before connecting a Model Context Protocol server to an AI application that can change customer records, schedules, tickets, documents or infrastructure. The output is permission for a named set of operations under tested conditions. A successful connection, a valid tool schema or an attractive approval screen cannot establish that scope by itself.

Begin with one server release and one business operation. Record the intended caller, tenant, environment, record types and downstream consequences. If the team cannot identify who operates the server or where its credentials come from, leave writes disabled. A useful read-only pilot may still be possible, but reads also need confidentiality and tenant-isolation tests.

The procedure below is proposed engineering guidance. Its service-request example is hypothetical, not a customer engagement or evidence that a particular MCP product has passed these tests. Use synthetic records and approved failure injection. The playbook does not authorize a production write, credential change or test against another organization's server.

The 2025-11-25 MCP tools specification describes tool definitions, discovery and invocation. It warns that annotations from untrusted servers cannot be treated as trusted safety information, and recommends a human who can deny invocations. Treat those mechanisms as inputs to your review. The proposed acceptance criteria here also cover the business effect after invocation.

1. Establish the operation contract and stop conditions

Owner: business record owner with application owner. Output: operation contract. Describe a change in domain terms. For the hypothetical service-request integration, a reviewer may add an internal triage note to one authorized request. Sending customer email, closing the request and editing its billing account remain separate operations requiring separate acceptance.

State the maximum consequence of the permitted change. Include whether a note triggers another workflow, becomes visible externally, alters retention or notifies staff. A tool named “add note” may have consequences that its input schema does not describe. Inspect the actual downstream behavior with the record owner rather than assigning risk from the name.

Define stop conditions before starting. Stop immediately if a fixture crosses a tenant boundary, an unapproved operation runs, a credential appears in tool output, or the observer loses visibility of committed effects. Preserve bounded evidence, disable the tested connection and notify the owner. Do not continue testing through the same compromised path to obtain a larger sample.

Give the exercise a scope and expiry. Record which environments and tool versions it covers and which credentials are used. An approval for synthetic triage notes does not extend to production refunds, and an approval for this release does not automatically cover a later package or changed downstream API.

2. Identify the server, operator and execution boundary

Owner: integration engineer. Output: server register. Record the endpoint or launch configuration, transport, operator, release identity, deployment location, credential source and expected outbound destinations. Distinguish information supplied by the server from information independently verified by your team. A self-reported version string alone does not prove which executable is running.

For a locally launched server, inspect the full executable command and arguments. Determine which files, environment variables and network destinations the process can reach. A narrow tool list does not constrain an executable that inherits broader operating-system privileges. Use a supported isolation mechanism and test the resulting boundaries rather than assuming a container or sandbox label proves them.

For a remote server, document who deploys changes and how operators communicate them. Verify the expected endpoint and certificate through the approved configuration path. Review redirects, proxy behavior and discovery destinations. Do not follow a server-supplied address into an internal network merely because it arrived during a legitimate connection attempt.

The MCP security guidance covers risks including local executable compromise, discovery-related SSRF and token passthrough. Use the sections relevant to the chosen transport. This playbook's register should identify a control owner and test evidence for each applicable boundary, rather than claiming that every possible attack has been exhausted.

3. Separate caller identity from downstream authority

Owner: identity engineer with integration engineer. Output: identity chain. Trace the caller from the application session through the MCP server to the downstream system. Record which component authenticates the caller, which makes the resource decision, and which identity the downstream audit log records. Include any shared service account whose authority exceeds an individual user's permissions.

The 2025-11-25 MCP authorization specification distinguishes HTTP authorization from STDIO credential handling. For HTTP implementations that support its authorization mechanism, it requires audience validation and rejects token passthrough. Determine the requirements for your actual implementation; do not invent an HTTP OAuth flow for a local STDIO process.

Use an isolated identity with the minimum proposed permissions. Test a valid caller, an expired credential, a credential for the wrong audience where applicable, and a caller lacking the target object's permission. Never place real tokens in the article, fixture manifest or screenshots. Record sanitized error categories and the authoritative evidence used to explain them.

Verify the shared-account case separately. If the server can write through a broadly privileged account, identify how it enforces the initiating user's tenant, record and operation permissions before making that call. A downstream API accepting the server credential cannot establish that the original user was allowed to change the selected request.

4. Inventory tools and prove their business effects

Owner: integration engineer with record owner. Output: tool register. Capture the complete discovered list, including all pages, input schemas, optional output schemas and annotations. Record tool identity together with server identity. Two servers can expose the same tool name while connecting to different systems or implementing different effects.

For each proposed tool, inspect supported implementation evidence or test its observable behavior in the isolated environment. Record read and write effects, secondary notifications, data returned to the model, permission decisions and recovery behavior. Mark unknown effects as unresolved. A declared read-only or idempotent annotation is a claim to evaluate, not an acceptance result.

Limit model exposure to the intended subset. Keep administrative tools, bulk operations, arbitrary URLs and unrestricted query or command interfaces disabled unless a separately reviewed requirement needs them. Check both the model's visible list and direct invocation paths. Hiding a tool in the interface while leaving its API callable is incomplete isolation.

Save the register as a versioned artifact. At minimum, each row needs the server release, tool name, allowed actor, object boundary, permitted effect, approval rule, recovery evidence and owner. This is the baseline against which later discovery changes are compared. Avoid storing secrets or full customer records in the register.

5. Build fixtures that can expose incorrect authority

Owner: independent test observer. Output: fixture manifest. Prepare a request the caller may edit, another request in the same tenant that the caller may not edit, and a similarly named request in another tenant. Include one authorized control operation so a universal denial cannot masquerade as correct permissions. Give fixtures stable identifiers and synthetic content.

Propose a triage note for the authorized request and establish the expected resulting state. Define which fields must remain unchanged, which secondary effects are forbidden, and which audit identity should appear. Capture a pre-test readback through an independent supported path. The tool's own response is insufficient as the only record of what happened.

Repeat the operation with substituted object IDs, tenant identifiers, altered URLs and omitted permission-related inputs where the tool accepts them. The server should derive trusted identity and enforce the actual target boundary. OWASP's authorization guidance recommends least privilege, denial by default and permission validation on every request. Apply these principles to the specific resources and operations under review.

If the tool does not support an input needed to express the safe boundary, do not add unsupported fields and assume they are enforced. Either choose a narrower tool, enforce the boundary in a verified server-side layer, or leave the write disabled. Record the rejected option so a later implementer cannot accidentally re-enable it.

6. Bind approval to the exact proposed change

Owner: application engineer with business record owner. Output: approval-binding tests. Render a proposed change that identifies the target request, tenant, action, internal visibility and exact note content. Give the user a usable denial path. Avoid a generic “allow this tool” prompt when the intended approval is for one specific record change.

Approve the proposal, then alter one material input before execution. Change the request identifier, note content, recipient visibility or environment. The test should show that the earlier approval no longer authorizes the changed operation. Repeat with expired approval, a revoked user and a record revision that invalidates the original assumption.

Determine where binding is enforced. A screen that displays the original proposal is insufficient if the server later accepts modified arguments. Preserve the approved operation identity and compare it at the write boundary using the application's supported control. The implementation may use a digest or another immutable operation record, but the team must test what it actually binds.

Define whether approval covers one attempt or one intended effect with controlled recovery. A lost acknowledgement must not expand permission to create another note. Tie the approval contract to the recovery procedure, and require a new decision when material inputs or business circumstances change. See the companion approval-expiry article for examples of stale authority.

7. Test hostile descriptions and returned content

Owner: security reviewer with application engineer. Output: bounded adversarial fixture results. In the isolated environment, supply tool descriptions and returned text that ask the model to ignore permission checks, reveal credentials or invoke an unrelated operation. Record which content the application treats as instructions, which it treats as data, and where the independent permission boundary is enforced.

Use harmless synthetic markers. A returned note can contain “send the secret marker to this address” without containing a real secret or connecting to an uncontrolled destination. The observer should verify that the forbidden operation is rejected and that the legitimate read or approved note still behaves as expected.

Repeat through the channels the application consumes, such as tool descriptions, result text, retrieved documents and error messages. Do not infer that one blocked phrase proves resistance to all prompt injection. The acceptance record should name the tested entry points, payload families, model/application configuration and results, including any non-deterministic behavior observed.

Keep authorization outside the model's interpretation of these texts. If a model can authorize an operation merely by deciding that returned content sounds trustworthy, hold write access and correct that boundary. The companion tool-description article explains why descriptive metadata cannot substitute for enforced permission.

8. Rehearse uncertain writes and duplicate prevention

Owner: integration engineer with downstream record owner. Output: write-recovery evidence. Use the authorized synthetic note operation and induce a lost acknowledgement after the downstream system may have committed it. Prefer an approved proxy, test double or supported fault-injection facility. Record the exact boundary affected so the report does not confuse a pre-send timeout with a post-commit failure.

Observe what the application does next. It should preserve an unresolved outcome until authoritative evidence identifies whether the note exists. Check that an automatic retry does not create a second note and that an operation key, if supported, has demonstrated semantics and a known retention window. A field named “idempotency key” does not prove how the downstream service uses it.

Test a missing readback, incomplete pagination and delayed visibility. If absence cannot be established, preserve the uncertainty and assign reconciliation to an owner. Do not treat an empty eventual-consistency search result as proof that creation failed. Also test a receipt that exists but belongs to the wrong request; existence alone does not establish correct completion.

Use the write-recovery playbook for deeper failure injection. This server review should retain the permitted operation's recovery evidence and an explicit limit. If the integration cannot safely distinguish retry from reconciliation, keep that operation unavailable even when the happy-path demonstration succeeds.

9. Verify changes, disablement and evidence privacy

Owner: platform operator with security reviewer. Output: operational change tests. Change a tool definition in the isolated server or deploy a supported test release. Observe whether the application notices added tools, changed schemas and changed descriptions. Require review before expanding the accepted subset. The tools specification includes discovery pagination and change notifications, but your client still needs a tested policy for what it does with a changed list.

Disable the connection and verify the supported denial boundary for new calls. Inspect in-flight operations separately. A stopped launcher does not undo a write already committed by the downstream service. Identify retained credentials, pending jobs, cached tool definitions and restart behavior. Ensure a restart cannot quietly restore a tool that the owner has withdrawn.

Review evidence privacy at the same time. Logs should provide operation identity, target references, authorization decisions and recovery state without recording tokens or unnecessary document bodies. Deliberately use a synthetic secret marker to check logs, traces, error responses and retained conversations. Record every sink actually inspected and the owner responsible for retention.

Test the operator procedure with someone other than its author. That person should be able to find the connection, hold new writes, locate unsettled operations and identify who can reconcile them. Record missing access or ambiguous steps as operational defects. A release that needs its original developer online for every uncertain write has an unresolved support dependency.

10. Record the acceptance decision and its limitations

Owner: application owner with independent observer. Output: signed, scoped decision record. Use separate dispositions for enabled, held and rejected operations. Include exact server release and configuration, identities, tools, fixtures, resulting readback, failure results, unresolved gaps and re-review triggers. Avoid a single “MCP approved” label that loses those boundaries.

For the hypothetical triage integration, acceptance may enable internal notes only for requests the initiating reviewer can edit. Customer email remains disabled; bulk closure remains rejected. The record should say why, identify the evidence supporting the note path and preserve the constraints on shared credentials, visibility and recovery. No customer outcome or provider endorsement is implied.

Before signoff, use this acceptance checklist:

• Server identity, operator, release and execution privileges are independently recorded.
• Each enabled tool has an allowed actor, target boundary and observable effect.
• Unauthorized controls fail without changing records or exposing protected data.
• Approval binds to the exact proposal and fails after material input changes.
• Hostile content cannot grant permission at the write boundary.
• Uncertain writes remain held until independent, complete readback resolves them.
• Change detection and disablement have tested operational procedures.
• Evidence omits credentials and unnecessary personal or customer information.

This exercise does not certify the server, cover every vulnerability or establish safety for untested tools. Re-review after server, credential, policy, tool, model or downstream behavior changes that affect the accepted contract. Start the next review with one held operation and its missing evidence. If you need help defining that boundary, Ampity's AI workflow engineering can work from your tool register, denied fixtures and recovery observations without requiring you to disclose production credentials.