Review an MCP Server Before Connecting an AI Agent

An MCP server is a program that exposes tools and data to an AI agent through the Model Context Protocol, and it can run on your machine or at a vendor. Review it in six steps before an agent can call it. Confirm who operates it, check how it authenticates you, and list its tools. Then treat every label as a claim, estimate what a compromised session could reach, and decide how you will notice changes. Finally, connect with the least-privileged credential that still lets you test.

Last reviewed: 2026-11-08. A review is a snapshot. It tells you what the server advertised and how it behaved on the day you looked. It does not prove the server is bug-free, that its operator will not change it, or that the text it returns is safe for a model to read. This guide is about the connection decision. For how an agent should handle retrieved content, see How to Handle Prompt Injection in Web Research Agents.

The protocol references used here were read on 2026-11-08: the MCP security best practices, the tools specification and the authorization specification. The spec evolves, so check the version a page names before relying on a detail.

First decide where the server runs

The checks differ depending on who executes the code.

The best-practices page covers local-server compromise: a locally started server runs with the client's privileges, so a one-click configuration should show you the exact command it will run, and limiting access (stdio transport, sandboxing) reduces the damage if it misbehaves (MCP security best practices). The authorization spec adds that authorization is optional and that stdio servers should take credentials from the environment rather than run an OAuth flow (MCP authorization).

For a remote server you cannot read the code, so you review the contract it exposes and decide how much the operator is trusted.

Step 1: Identity and provenance

Establish that the endpoint belongs to the party you think it does.

• Remote: take the URL from the vendor's own documentation, not from a search result or a chat message. Check that the hostname is on the vendor's domain.
• Local: read the exact command and arguments the client will execute. Pin a version instead of a floating tag, and look at what the install step runs. Prefer launching it inside a sandbox or container with only the directories it needs.

If you cannot tie the server to a publisher you can name, stop here.

Step 2: Authentication, checked from the outside

For a remote HTTP server, the spec requires the server to publish OAuth 2.0 Protected Resource Metadata (RFC 9728), and clients use it to discover the authorization server (MCP authorization). That metadata is public, so you can read it before connecting anything.

Here is the check against the ReplyNodes MCP server, run with curl -i on 2026-11-08:

curl -i https://mcp.replynodes.com/.well-known/oauth-protected-resource

It returned HTTP/2 200 with content-type: application/json, and this body:

{"resource":"https://mcp.replynodes.com/mcp","authorization_servers":["https://auth.replynodes.com"]}

Compare three things:

1. The resource identifier matches the endpoint you will configure. Here resource is https://mcp.replynodes.com/mcp, the same URL a client would connect to. A mismatch is a reason to stop.
2. The authorization server is one you expect. Here it is https://auth.replynodes.com, a sibling host under the same vendor domain.
3. The metadata is served over HTTPS from the vendor's host.

The spec requires clients to send the resource parameter from RFC 8707. It also requires servers to validate that a token was issued for them and to refuse tokens meant for other services. Tokens belong in the Authorization: Bearer header on every request, never in a URI query string (MCP authorization). You cannot verify audience validation from outside, but you can check that no setup instruction asks you to put a token in a URL.

Next, read the authorization server's own metadata (RFC 8414):

curl -i https://auth.replynodes.com/.well-known/oauth-authorization-server

On 2026-11-08 this returned HTTP/2 200 with content-type: application/json. The body began with:

{"client_id_metadata_document_supported":true,"scopes_supported":["mcp:read","offline_access"],"issuer":"https://auth.replynodes.com", ...

Three fields matter for the review:

• issuer should equal the authorization server named in the resource metadata. It did.
• code_challenge_methods_supported was ["S256"], the PKCE method defined in RFC 7636. The authorization security considerations tell clients to use S256 when technically capable, and to refuse to proceed if that field is absent (authorization security considerations).
• scopes_supported listed mcp:read and offline_access. A scope named for reading is consistent with a read-only intent, which is a claim to test in Step 4, not proof. The best-practices page advises minimal scopes and avoiding omnibus or wildcard ones.

The same document also listed client_credentials among its supported grant types. Metadata describes what the authorization server supports in general, not which flows apply to your client, so treat an unexpected grant type as a question to ask the operator rather than a finding.

Redirect URIs deserve a glance when you register a client: the security considerations require authorization servers to match them exactly and require them to be either localhost or HTTPS. That is enforced between your client and the authorization server, so a metadata read cannot confirm it.

Step 3: Read the tool surface

Authentication tells you who you are. The tool list tells you what the model can do. With a low-privilege credential, run tools/list through your client or an MCP inspector and record each tool's name, description and input schema in a file you keep.

Then ask, for each tool:

• Does it match the server's stated purpose?
• Does it write, delete, send, pay or execute? If so, does your use case need it?
• Is the description a plain statement of capability, or does it contain instructions aimed at the model ("always call this first", "do not tell the user")?
• Are the input schemas narrow (typed fields, enums) or free-form strings that are passed through to a shell, query or URL fetch?

The tools spec says tools/list may vary with the authorization presented on the request, so repeat the listing with each credential class you plan to use. A list that looks harmless with a restricted key does not describe what an admin key would see.

This guide does not list ReplyNodes tool names or counts. The tool inventory of a live server is something to read from the server at review time, which is the point of this step.

Step 4: Treat annotations and descriptions as claims

Tools can carry annotations such as a read-only hint. The tools spec says clients must consider annotations untrusted unless they come from trusted servers (MCP tools specification). The same wording appeared in the 2025-11-25 version, so it is not a recent quirk.

So a label saying "read-only" is where verification starts. Verify read-only behavior in three ways:

1. Token scope. What does the credential permit on the server side? A read-only scope on the token is a stronger signal than a label on the tool, because the server's access control enforces it.
2. Reach. What systems can that credential touch? A read-only tool backed by an administrator token to a private database is still sensitive.
3. Behavior. With a test credential and a disposable or empty account, call each tool you intend to expose and confirm it does what the description says and no more. Check the target system afterwards for changes.

A dry run with a test key is cheap, and it surfaces surprises: a tool that needs a scope you did not expect, a response that is far larger than the description implied, or a call that fails open.

Step 5: Estimate the blast radius

Assume the model will be steered at some point, by a malicious page or a bad tool result. Ask what the worst realistic outcome is given the connection:

• What the credential can read. Private data the model can read can be repeated in its output.
• What the server can reach. For local servers, network egress and environment secrets. For clients, the best-practices page warns about SSRF during OAuth discovery: require HTTPS, block private and link-local ranges, validate redirects.
• Scope. Start with the minimum and raise it only when a task demands it.
• Human approval. The tools spec says there SHOULD always be a human in the loop with the ability to deny invocations. That is a client feature, not a server guarantee, and the spec word is SHOULD. Approval prompts also cause fatigue, so a small tool surface works better than a long one with a prompt on every call.

Step 6: Operational controls

After you connect, the review needs a maintenance plan:

• Pin and re-review on change. Record the version of a local server and the tool list from Step 3. When either changes, repeat the review. Servers can announce list changes (the listChanged capability in the tools specification), and a diff of the saved listing catches silent description edits.
• Log tool calls on the client side. The tools spec says clients SHOULD log, show tool inputs to the user, validate results and time out calls. If your client does not, put those controls in your own wrapper.
• Know whose job each control is. The client enforces consent and approval. The server enforces token audience validation, input validation, access control, rate limiting and output sanitization, per the spec's security considerations. You can ask about server-side items but not observe them, so record them as claims.
• Know how to revoke. Before you connect, find out where to revoke the key or grant, and write it down.

Worked example: a hosted, read-only MCP server

The ReplyNodes MCP server is a hosted remote server at https://mcp.replynodes.com/mcp. The published product facts describe interactive OAuth through https://auth.replynodes.com with scope mcp:read. They also describe manual setup with an rn_test_* or rn_live_* API key sent as a Bearer credential; organization context resolved from the authenticated identity rather than sent by the client; and a read-only public-data boundary. Step 2 above checked part of that from the outside on 2026-11-08: the resource metadata names the endpoint and issuer above, the authorization server metadata reports the same issuer, lists the mcp:read scope and advertises S256 PKCE. The API-key setup, identity resolution and read-only boundary come from the published product facts and are not something a metadata read can confirm.

Applying the remaining steps:

• Step 3 and 4: run tools/list with a test key and compare the result to the read-only claim. The claim is a product boundary, not a label to accept. Check that no listed tool sends, writes or executes anything, and that the descriptions are plain.
• Step 5: the credential reaches public data (web search, public pages and similar read endpoints), not your private systems. Current providers and routes come from the live capabilities document at GET https://api.replynodes.com/v1/capabilities, not from this article.
• Step 6: read the MCP page and the security page for the product's own statements. This article asserts nothing about rate limits or server-side logging, because neither is documented in the product facts used for this review.

What this review does not tell you:

• A read-only boundary reduces mutation risk. It does not stop prompt injection in returned page text, data exposure to the model, or inaccurate results.
• It is not an audit or certification of ReplyNodes, and no such claim is made.
• It does not tell you how your model will behave with the output.

For the second and third points, see the prompt injection guide.

Match the review to the risk

Heavy enterprise machinery (gateways, policy engines, central inventories) can be disproportionate for one developer connecting one hosted server. It starts to pay off when many people connect many servers. Scanners and trust scores can add signal, but treat their output as a hint, not a verdict, and this article does not recommend or evaluate any.

Pre-connection checklist

• The endpoint URL came from the vendor's own docs.
• Resource metadata resource matches the configured endpoint.
• The authorization server is expected and advertises S256 PKCE.
• No instruction places a token in a URL.
• The tool list was recorded with each credential class.
• Every write, delete, send or execute tool is justified or removed.
• Descriptions contain no steering instructions.
• Read-only was verified by scope and by a test, not by a label.
• The client asks for approval on any consequential call.
• Revocation steps are written down.
• A date is on the review, and a trigger for repeating it.

FAQ

Is a read-only MCP server safe?

Safer than one with write tools, not safe in general. It limits changes through that connection. Returned content can still carry instructions and the model can still repeat data it can see.

Do I need to read the source of a hosted server?

Usually you cannot. Review the public contract (metadata, tools, scopes), test with a low-privilege credential, and decide whether you trust the operator with the data you send.

Do tool annotations prove a tool is read-only?

No. The spec tells clients to treat annotations as untrusted unless the server is trusted. Verify by token scope and by testing.

How often should I re-review?

Whenever the server version, tool list or requested scope changes, and on a schedule that fits how sensitive your data is. There is no spec-defined interval.

Next step

If you want a hosted read-only example to practice on, start with the endpoint, scope and read-only details on the ReplyNodes MCP page and work through Steps 1 to 4 against them. Then create a key at platform.replynodes.com/api-keys and use it in a test client. For REST access to the same kind of data, see the API page.

Related reading: MCP vs REST API for AI Agents, Best MCP Servers for Web Research and Scraping and How to Build an AI Web Research Agent.