A Security Checklist for Remote MCP Servers

An MCP server is a trust boundary wearing a JSON-RPC costume. Point an agent at one and you're handing it a list of callable actions, described in natural language the agent takes at face value, sometimes backed by credentials the server holds on your behalf. None of that is visible from a health check that just confirms the endpoint answers. This is a checklist for what you can verify from the outside — operating a server, or deciding whether to point an agent at one you don't control — plus an honest accounting of what no external probe, including Merlonix's, can see.

Transport: TLS or plaintext

The cheapest check, and the least excusable to fail: is the endpoint served over HTTPS? If not, every JSON-RPC request an agent sends — including any bearer token or API key attached to it — travels the wire in the clear, readable to anyone positioned between agent and server. There's no tool-level mitigation for this; it's fixed at the transport, or it isn't fixed.

Operators: serve your MCP endpoint over HTTPS only, and confirm a reverse proxy isn't silently downgrading TLS upstream.
Agent developers: treat a plaintext http:// MCP endpoint as disqualifying for anything carrying a credential — not a "warn and proceed" situation.

Merlonix's MCP health checker grades this as its transport dimension: HTTPS scores 100, plaintext HTTP scores 20 and produces a fail finding, regardless of anything else about the server — the endpoint's own scheme, separate from which wire transport the server speaks (Streamable HTTP vs the legacy SSE transport covered in Streamable HTTP vs SSE).

Authentication, and what an unauthenticated surface exposes

Does the server challenge for a credential (401/403), or answer initialize and tools/list to anyone who asks? An unauthenticated MCP server isn't automatically wrong — a read-only public catalog search has little to protect. But one that exposes tools able to write, delete, or reach anything sensitive hands every caller on the internet the same access a legitimate agent has, with no way to tell them apart in logs and no way to revoke one caller without revoking all of them.

Operators: if any exposed tool can mutate state, read anything non-public, or spend money, put the server behind auth. If it's intentionally open, keep the surface narrow enough that "anyone can call this" is a decision you made, not a default.
Agent developers: an unauthenticated server tells you nothing about who else is calling it or what they've done with the same tools. Check what the tools can actually do before pointing a production agent at one — read-only and mutating tools deserve different trust.

Merlonix's security posture grades this as its authentication dimension: a 401/403 challenge scores 100; no challenge scores 55 and produces a warn finding, not a pass — a large share of public MCP servers require no auth at all.

Tool poisoning: what the description and schema can hide

This is the attack class specific to MCP. An agent reads a tool's name and description as instructions, not just documentation — a tool description is prompt content the model will act on. A malicious or compromised server can bury an instruction in a description that a human skimming the tool list would never notice, and an agent will follow it.

Concrete patterns worth scanning for in tool names and descriptions:

Instruction-override or assistant-redefining language: "ignore all previous instructions," "disregard the system prompt," "you are now," "new instructions."
Hidden-instruction markup — <important>, <system>, <secret>, <admin> tags embedded in what should be plain documentation.
Language telling the agent to act without telling the user ("do not mention," "without informing the user"), or coercive priority claims ("always call this tool first") meant to make a poisoned tool intercept traffic meant for a legitimate one.
Exfiltration hints — references to .env, SSH keys, or instructions to forward secrets, tokens, or credentials.
Invisible or zero-width characters hiding text inside an otherwise normal-looking description.

Merlonix's live security posture check scans every advertised tool's name and description against exactly these signal categories (scoreMcpSecurityPosture in the health checker). Any flagged tool hard-caps the overall grade at C — a server with even one poisoned tool never reads as safe overall, regardless of how clean its transport or auth posture is.

The honest limit: this only works on what the probe can read. If the server is auth-gated, tools/list is invisible to an unauthenticated check, so the scan has nothing to scan — Merlonix's grader marks that dimension informational (zero weight) rather than pretending an unscanned server is clean. A server can also poison a description after you've added it to your agent, or serve different descriptions to different callers. Schema fields other than description — parameter descriptions, enum values, default strings — can carry the same payloads.

Operators: audit your own tool descriptions like user-facing copy that happens to run through an interpreter — no embedded directives, nothing addressed to the model instead of the reader.
Agent developers: read tool descriptions before trusting them, especially for servers you didn't write. A tool that insists it must always run first, or tells the agent to keep something from you, is the tell.

Over-broad tool surfaces

Every tool a server exposes is something an agent might call, correctly or by confusing it with something else. A server with three well-scoped tools gives a poisoned or mistaken call far fewer places to land than one with sixty overlapping ones. Tool count isn't itself a security score — Merlonix's live posture grader above only covers poisoning, auth, and transport — but it's worth checking by hand: pull tools/list, note how many tools there are, how much they overlap, and how many can write versus only read. How many MCP tools is too many? covers the usability side; the security angle is the same shape — a narrower surface is a smaller blast radius.

Operators: don't expose a tool because your underlying API has the endpoint; expose it because an agent needs to call it. Omit anything with irreversible side effects (deletes, sends, payments) unless the use case requires it.
Agent developers: check whether a server needs the access it grants. Fifteen mutating tools when your agent only needs to read is more risk than the task calls for.

Confused-deputy risk: when the server holds credentials on your behalf

Many remote MCP servers act as a deputy — they hold a token to some third-party API (your calendar, your CRM, your cloud account) and expose tools that use it on the agent's behalf. That's the entire point of most useful servers. It's also exactly the shape of a confused-deputy problem: the agent asks the server to do something, the server has more authority than the request should carry, and nothing in the protocol enforces that the server only uses that authority as you intended.

This is the item no external probe can verify. A health check, a security-posture grader, an mcp.json manifest — none can see what a server does with a credential once your request reaches it, whether it scopes that credential per-caller, or whether a bug (or a malicious operator) lets it exceed what the agent asked for. That's server-internal behavior, invisible from the wire. What you can do without trusting blindly:

Operators: scope every credential to the minimum the exposed tools need, not to what your integration happens to have, and log what each call does with delegated access so a compromised call is auditable after the fact.
Agent developers: ask what a server's credential can do beyond what its tools expose — an OAuth token scoped to "read your calendar" that the server could also use to write is a confused-deputy risk even if every current tool is read-only. Prefer the narrowest scope your use case allows over a broad one "in case you need it later."

Observability: knowing when the surface changed

A server that was safe yesterday isn't guaranteed to be safe today. Tool descriptions get edited, new tools get added, auth gets turned off during a deploy and forgotten. A one-time check is a snapshot; the risk is ongoing.

Two things make drift visible instead of silent: a stable digest per tool, hashing its name, description, and input schema together, so any edit to any of the three — including a description that quietly grows an injected instruction — changes the digest; and comparing what a server declares against what it serves, since some servers publish a .well-known/mcp.json manifest describing their tools, and diffing that declared list against the live tools/list result catches a tool the manifest promises but the server doesn't have, or one the server serves that the manifest never mentioned.

Neither means anything as a one-shot check — both need a previous run to diff against. That's continuous monitoring versus a point-in-time scan: the same probe on a schedule, with each run's inventory compared to the last one's, turns "the server got riskier" into an alert instead of something you find out about later. Merlonix's MCP health checker runs the transport, auth, and tool-poisoning grade described above for free on any URL, no signup; the scheduled version with drift detection and the manifest-vs-live comparison is on the paid plans. See how to health-check a remote MCP server for the broader "up" question this same probe also answers.

What this checklist is not

None of the above is a security audit, and nothing that grades from the outside — Merlonix's tool included — can be one. An A grade on transport, auth, and tool-poisoning heuristics means those three externally-observable dimensions look clean right now; it says nothing about the server's internal secret handling, what its code does when a tool is called, or how it uses any credential you hand it. Treat this as the floor you check before extending trust, not the ceiling trust requires. The MCP server developers hub collects the rest of the toolchain, and the MCP directory is a reasonable place to see how live servers present their transport, auth, and tool surface once you know what to look for.