Review a remote MCP server before connecting it

Suppose you're connecting a support assistant to your ticketing system through an MCP server. The assistant needs to search tickets and add internal notes. The server also offers a customer-export tool. Should the assistant be able to call it?

That question is the start of the review. A successful connection tells you the server works. Before using it in production, you also need to know what the agent can do, whose permissions it uses, and what happens when a call fails.

We'll use this support assistant as a running example. Work through the questions with the server owner, alongside your usual checks on server hosting and software dependencies. The checklist at the end gives you a record of the decision.

What can the agent actually do?

Start with the full tool list and compare it with the assistant's job. In this example, ticket search and note creation belong on the approved list. Customer export doesn't. Check what each tool actually does, too: a tool labeled “search” might return a single ticket or thousands of records.

Test the restrictions using the credentials the agent will use. An allowed ticket search should succeed. An attempt to call the export tool should be denied. Checking that export is missing from the tool list isn't enough; try calling it directly.

In Dome, use the Tool Gateway to give the agent access to the required tools and apply Rules to their use. Run the tests through that Gateway, and check whether the agent has any credentials or routes that would let it reach the server directly.

Whose permissions does the server use?

Ask which account the ticketing system sees when the assistant adds a note. Is it the employee requesting the change, or a shared service account?

A shared account may have access to tickets the employee can't see. If access must follow the employee's permissions, the integration needs a verified user identity and a check against the ticketing system's records. An email address supplied as a tool argument isn't proof of identity. Test with a ticket that the employee isn't allowed to access.

Keep the credentials for each connection separate. Under the MCP authorization specification, the MCP server must validate that an incoming access token was issued for that server. It must not accept a token meant for the ticketing API and simply pass it along. Record where credentials are stored and who rotates them. Dome's Tool Gateway manages credentials for its upstream connections without exposing them to the agent.

For the distinction between connecting an account and permitting a particular action, see MCP authentication vs. authorization.

What data comes back to the agent?

A permitted search can still return more information than the assistant needs. A ticket response might include the customer's email address and phone number alongside the issue summary.

Agree with the data owner on which fields the assistant needs. Remove unnecessary fields at the source where possible. For calls through Dome, configure Guards to inspect requests and responses and apply the required blocking or redaction.

Then run a test with synthetic contact details and inspect what the agent actually receives. A saved configuration doesn't tell you whether a nested field survived in the response.

What happens if a write times out?

The assistant sends a note. The ticketing system saves it, but the response never reaches the assistant. Retrying immediately could create the same note twice.

Reproduce that failure in a test environment: save a harmless note, then interrupt the response. Check whether the application can establish that the note was saved before trying again. If it can't, keep note creation disabled until there's a safe recovery procedure. A timeout alone doesn't tell you whether the write happened.

Where else can the connection send requests?

If a tool accepts a URL or repository name, find out whether the caller can choose any destination or only an approved one. Reviewing the MCP server's hostname won't answer that question.

There is also traffic before the first tool call. During OAuth setup, the MCP client may fetch metadata and follow URLs supplied by the server. A malicious server could direct those requests toward an internal service. The MCP specification covers this under server-side request forgery.

Test that the deployed client rejects an unapproved destination, including after a redirect. Restrictions on tool traffic may not cover the separate component fetching OAuth metadata. If your setup needs an internal authorization service, approve that destination explicitly.

The checklist to take into review

For each item, record an owner, a test result or supporting document, and any unresolved work. Mark “not applicable” with a reason.

• Ownership: Who maintains the server, and who will notify you when its tools or behavior change?
• Tool access: Do required calls succeed and prohibited calls fail, using the agent's actual credentials?
• Identity and permissions: Whose account reaches the backend, and what prevents access to another user's records?
• Credentials: Does the server validate incoming tokens? Who stores and rotates the upstream credentials, without exposing them to the agent?
• Data: Do the request and response controls handle the sensitive fields in your test cases?
• Failure recovery: Can the application handle a denied call, a failed call, and a write whose result is unknown?
• Destinations: Are tool destinations and OAuth-related requests restricted, including redirects?

Keep the server version, approved tool list, review date, and test records together. Another reviewer should be able to follow an allowed call, a denied call, and a failed call and explain each outcome.

For the support assistant, the decision might be: ticket search approved, customer export blocked, note creation waiting on the recovery test. When the server or its tools change, revisit the checks those changes affect.