You already run MCP servers. Who's read them?
MCP deployments are a new attack surface with its own named failure modes — tool poisoning, over-broad scopes, agents reaching further than anyone intended. I review servers you're already running, whether you built them, generated them, or got them from a vendor. Fixed fee, written findings, prioritised.
What I look for
Four questions, answered against your actual deployment rather than a checklist.
Tool poisoning
An MCP tool's description is instruction text the model treats as trusted. Poisoned descriptions and parameter schemas ride in at a layer your users can't inspect and your agent has no reason to doubt. I read what your server actually advertises, not what its docs say it does.
Scope that's wider than you think
Most over-reach isn't malicious, it's inherited: a token minted for convenience, a read scope that quietly includes write, a service account with more than the agent needs. The question I answer is the specific one — given this server and these credentials, what could an agent reach if it were asked to?
What you can prove after the fact
When an agent does something surprising, can you reconstruct which tool it called, with what arguments, on whose behalf? Audit trails tend to be the last thing added and the first thing needed. I check whether yours would survive the question.
Third-party and generated servers
Servers you didn't write are the growth area — vendor-published, community, or generated. They deserve the same review as your own code and usually get less. Bring one you're evaluating and I'll tell you what it does before you point an agent at it.
What this is, and what it isn't
- It is a hands-on read of your MCP servers and the boundary around them: what they expose, what an agent could reach through them, where auth is doing less work than you'd assume, and what to fix in what order.
- It isn't a compliance certificate, a penetration test of your whole estate, or a scanner subscription. I'm an integration engineer who has spent close to a decade inside other people's systems — that's the lens, and it's the one that catches over-reach.
- You keep the findings whether or not I do the remediation. If the fixes are yours to make, good — the report is written so your own team can act on it.
Bring me a server
Tell me what you're running and what it's connected to. If a review is the wrong call I'll say so — sometimes the honest answer is that your scopes are fine and the risk is somewhere else entirely.