Skip to main content

Check an MCP config before you connect it

MCP servers give an AI assistant tools, and the text that describes those tools goes straight to the model. Paste a config or a tool list and see what is hidden in it, what is open to anyone, and how much of your machine it can reach.

The four groups of checksFour groups: hidden text in descriptions, instruction-like wording in schema fields, servers with no authentication or plain http, and wide reach such as whole-disk access or command execution.Hidden textInvisibleUnicode,comments, oddtagsInstructionsPrompt-like textin descriptions,defaults andparametersOpen doorsRemote serverswith no sign-in,plain http, keysin the fileReachWhole-diskpaths, shells,unpinnedpackages
Each finding shows where it is in your paste, what was seen (invisible characters made visible), why it matters and what to do.

Checked in your browser. What you paste is not sent anywhere.

Where a poisoned description gets in

How hidden text in a tool description reaches the modelFour steps: a server publishes a tool with a description, the client lists the tools, the model reads the full text including anything hidden, and then calls tools with your access.1ServerPublishes a tooland itsdescription2ClientLists the toolsit was given3ModelReads all of thetext, hidden ornot4ToolsCalled withyour access
The checker reads the full text of every description, including text a person may not notice.

Why descriptions matter

Invariant Labs defines tool poisoning like this: “A Tool Poisoning Attack occurs when malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models.” (Invariant Labs)

The MCP specification says descriptions of tool behaviour, such as annotations, should be considered untrusted unless they come from a trusted server.

That is why the checker reads every description, title, default and example in a tool’s schema, not just its name.

What the specification says about your config

  • The security guidance lists a malicious startup command in a client configuration as an attack on local servers.
  • A client that supports one-click setup of local servers must show the exact command that will be executed, without truncation.
  • Clients should warn that servers run with the same privileges as the client.
  • Authorization is optional.

Those are the reasons for the checks on how a server is started, how wide its access is and whether a remote one asks anyone to sign in.

Questions

Is what I paste uploaded?

No. The check runs in your browser and the page makes no request with your text. It is not stored. Even so, remove real keys from a config before you paste it into any web page.

Does "nothing flagged" mean the server is safe?

No. The checks look for patterns: invisible characters, hidden markup, instruction-like wording, missing authentication and wide access. Instructions written in ordinary words, and what a server does at run time, are not visible in a config. Read the descriptions yourself and test the server.

Why does it flag a remote server with no authentication?

Nothing in that entry sends a credential, so the server may answer anyone who finds its address. Your client may still start a sign-in when it connects, so treat the flag as a prompt to check.

What formats does it read?

JSON from Claude Desktop, Cursor and similar clients (mcpServers), VS Code (servers, comments allowed), a tools/list response, or a plain list of tools. Anything else is scanned as text for invisible characters, hidden markup and instruction-like wording.

Is this a penetration test?

No. It is a quick review of one file. A test of an agent covers the model, its tools, the data it reads and the access it holds, and tries to make them fail.

Related tools and guides