Who reads the tool descriptions?

Open your MCP config and look at the servers in it. Now think about the last time you read one of their tool descriptions. I mean the paragraph under the tool name, the text the model actually gets. If you're like most of us, the honest answer is never.

Your agent reads all of it, on every request, and treats it as instructions. That's what it's for. MCP, the protocol Anthropic put out in November 2024,¹ made it very easy to plug a new tool into an agent, and almost nothing about that flow asks you to look at what the tool is telling the model.

A calculator that wanted your SSH key

In April 2025 a team at Invariant Labs showed how badly this can go.² They built a server with a harmless-looking calculator tool and hid instructions in its description. Go read the user's SSH key and MCP config, they told the model, and pass them along in one of the tool's parameters. The agent did it. The person at the keyboard saw a calculator.

The part of that advisory we kept coming back to was shorter. They called it a rug pull. You can read every description carefully on the day you install a server, and the server can change them next week. In most setups, nothing will tell you it happened.

If you work at a bank or an insurer, try explaining that one to your risk team. The agent has real access to real systems, and the instructions steering it were written by someone outside the company that nobody inside has read.

So we built something to read them

MCPsight is a command-line tool. Point it at one server, or at your whole config, and it tells you what's in there.

mcpsight scan --from claude_desktop_config.json

It goes through every tool description looking for the things you'd hope never to find. Text telling the model to ignore what it was told. Text pointing at ~/.ssh or .env. Characters that don't show up on screen when a human reviews it.

Local servers get run in a sandbox with no network and a fake home directory, and we leave decoy credentials lying around in it. A server that goes looking for a fake SSH key the moment it starts has told you most of what you need to know about it.

It also counts how many tokens the tool definitions add to every request, which is worth knowing when you pay per token, and checks the usual supply-chain things like install scripts, known CVEs and package names that are one letter off a popular one. Each server ends up with a grade. The rubric behind it is published in the repo, so you can redo any score by hand from the findings. If the people who need this answer are auditors, they should be able to check our arithmetic.

Why it's built to live in CI

A scan you run once only helps on that day, and the rug pull happens later. So every scan writes a baseline file that you commit next to your config. In your pipeline you run mcpsight verify, and if a server's tools have changed since the baseline, the build fails.

mcpsight verify    # exits non-zero if a server changed under you

It pays attention to which way things moved. A description that got shorter is fine. One that suddenly contains an instruction, or a tool that used to read files and now writes them, gets flagged hard.

What it won't do

It isn't a malware scanner, and we're not going to pretend it is. Code written to hide from its tracing can hide. Local servers only scan on Linux for now, because that's where the sandbox works. On a Mac or Windows it refuses to run them unsandboxed, and you can still scan remote ones. It's also version 0.1.0, out since 3 October, so expect rough edges.

It's open source under Apache-2.0, it runs offline, and there's no account to create. Grab it from mcpsight.dev and run it against your own config. If it finds something, or gets something wrong, we'd like to hear about it.