Paste a remote MCP server URL and see what an agent sees: the protocol version it negotiates, every tool it advertises, and any tool-poisoning patterns hiding in the descriptions. Servers that need a sign-in get their OAuth discovery chain checked instead. Nothing is called and no credentials are sent.
check_mcp_server, so an AI agent in your browser can run the check and read the JSON back instead of
filling in the form. How it works Try: , ,
It connects over Streamable HTTP the way a current client does: first the stateless server/discover call from the 2026-07-28 spec, then the initialize handshake if the server does not support it. It records the negotiated protocol version, the server name and version, and how long the handshake took. It then pages through tools/list and shows every tool with its parameters and its readOnlyHint / destructiveHint annotations, plus an estimate of how many tokens of context the tool list costs an agent before the user types anything.
If the server answers 401, the checker walks the discovery chain a client follows to sign in: the WWW-Authenticate challenge, protected-resource metadata (RFC 9728), authorization-server metadata (RFC 8414), an issuer that matches (the RFC 9207 mix-up defence), PKCE with S256, and a client registration path - client ID metadata documents, or dynamic registration, which the 2026-07-28 spec deprecates. It also looks for a Server Card at /server-card.
An agent trusts whatever a server says in tools/list. Descriptions and server instructions go straight into the model's context, so a description is an instruction to every agent connected to that server. The lint flags the patterns used to abuse that: hidden Unicode (zero-width, bidi-control and tag characters a model reads and a person does not see), instruction markers such as <IMPORTANT> or "do not tell the user", credential-file paths like ~/.ssh or .aws/credentials, cross-tool steering that tells the agent how to use another server's tool, encoded blobs, and oversized descriptions. False positives happen; each hit shows the excerpt so you can judge it.
A clean result today says nothing about next week. The documented attacks on MCP are changes after trust was given: a server that was fine when it was approved ships a new version whose tool descriptions ask for more. A one-off check also cannot see servers that behave differently per client, and it never calls a tool. Local stdio servers are out of reach from a website; this checks remote servers only.
AlertKick's MCP monitor runs this check on a schedule from the locations you pick. The first tool list becomes the approved baseline; an added tool, a changed description or schema, or a tool that stops being read-only fails the check until a person approves it. Agents and API keys cannot approve their own tool changes. Alerts go through the same on-call and escalation as the rest of your monitoring. Free to start.