Project summary

MCP servers hand the model a list of tools at the start of every session. The description text in that list is part of what the model reads. That makes it an attack surface, not documentation.

The payload never touches disk. That is the whole problem. Package pins and config hashes both watch the filesystem, and a server can change what it tells the model without changing a single byte there. postmark-mcp shipped about fifteen clean releases with an identical config file, then changed what tools/list returned.

Agentmetry fingerprints the schema the model was actually handed. It flags the case where that digest moves while the config digest holds still. It runs locally, writes to a hash-chained file the operator owns, and forwards into whatever SIEM they already run. No vendor cloud, no telemetry back to me. Apache-2.0, on PyPI, working today.

The MCPTox benchmark is why I think this is worth funding. Twenty LLM agents against 353 authentic tools across 45 live servers. Average attack success rate 36.5%, peaking at 72.8%. The best refusal rate was still under 3%. More capable models did worse, because the attack exploits instruction-following.

What are this project's goals? How will you achieve them?

The goal is that someone running a coding agent can tell when a tool was swapped underneath them. On their own machine. With evidence that survives the incident.

Six pieces of work. The first three are unglamorous, and they go first.

1. Split the digest by severity. One hash over the whole schema treats an added optional field the same as a rewritten description. Two digests instead: one over every string the model reads, one over structure.

2. Make it auth-aware. tools/list is a property of the session, not the build. Servers return fewer tools before OAuth completes, so today an expired token can look like an attack.

3. Stop scoring a failed fetch as tools removed. Some registries return 410 intermittently. That is a transport failure, not a schema change.

Those three come first because of what happens if they don't. If a user's own expired credentials fire the first two alerts, nobody reads the third. Precision is not polish here. It is the difference between a detector and a thing people mute.

4. Capture the initialize handshake. serverInfo.version and capabilities.tools.listChanged cross the wire every session and I currently throw both away. Digest moved plus version moved reads as a normal release. Digest moved plus version unchanged is the attack shape. The version is attacker-controlled, so this separates ordinary churn from suspicious churn and is not a security boundary. Worth saying out loud rather than letting someone assume otherwise.

5. Detect call-time drift. A server can keep the tool list identical and change behaviour when a tool is actually called. Fingerprint the response shape — key paths and types, no values — so nothing poisoned is ever stored.

6. Grow the corpus past one machine. The benign sessions matter more than the attack ones.

How I will know it worked: the benchmark is the measure, and it is a command anyone can run in about ten seconds. Today it is 50 recorded sessions, 26 attack and 24 benign, covering 13 of the 15 rules, with 0 missed and 0 false positives on that corpus. Success looks like more rules covered, benign sessions from machines that are not mine, and a false-positive rate that survives expired tokens and routine schema updates.

How will this funding be used?

Minimum $5,911 buys about 8 weeks part-time for items 1 to 4. Plus API credits and Windows test VMs. Goal $23,117 buys 6 months at 50% time for all six items, including the call-time sensor and a multi-machine corpus. Split at goal: 70% stipend, 9% API credits, 12% infrastructure, 9% buffer. Stipend benchmarked to a senior security engineer rate in Greece, gross of income tax and EFKA. Showing the derivation beats stating a number.

Who is on your team? What's your track record on similar projects?

Minimum, $5,911: about eight weeks part-time. Items 1 through 4, plus model API credits, Windows test machines, and MCP server access.

Goal, $23,117: six months at half time. All six items, including the call-time sensor and a corpus drawn from more than one machine.

At the goal: 70% stipend, 9% API credits for corpus generation, 12% infrastructure, 9% buffer. The stipend is benchmarked to a senior security engineer rate in Greece, where I am, gross of income tax and social contributions.

Who is on your team? What's your track record on similar projects?

One person, part-time, alongside other work. No employees, no organization.

What exists: 1,130 passing tests at 81% coverage, zero open code scanning alerts, CI on Linux and Windows. Fifteen sequence detection rules mapped to MITRE ATT&CK and ATLAS, exported as Sigma rules generated from the engine so the severities cannot drift. I have run the sensor against my own work since 2026-08-08, and the last 30 days recorded 30,999 events across 170 sessions from five different agent surfaces. The detection ruleset is frozen behind a published fingerprint during the evaluation, so four clean weeks cannot quietly mean four different rulesets.

The thing I would actually point at is not a success.

I posted this work to r/mcp and asked to be told the heuristic was too weak. Six specific critiques came back instead of praise. One reviewer showed that the severity split I was about to ship would have demoted property-level description and title fields into the low-severity bucket. Those strings are model-visible. They are the attack surface. I would have shipped it, called it an improvement, and made the tool quieter about the exact thing it exists to catch.

I filed four issues against my own tool that day. The thread is public: https://www.reddit.com/r/mcp/comments/1vvinyo/

What are the most likely causes and outcomes if this project fails?

Nobody installs it. 233 downloads a month, zero external users. A detector nobody runs catches nothing. That is the most likely failure, and it is not a technical one, which is uncomfortable given that engineering is the part I am good at.

The signal gets too noisy and people mute it. A muted tool is worse than no tool, because it leaves someone believing they are covered. That is the entire reason items 1 through 3 come before the interesting work.

Attackers stop touching the schema at all. The call-time sensor is the answer, and it is the hardest piece. Built badly, it adds noise without adding coverage.

If it fails, the benchmark and the recorded corpus stay public and Apache-2.0, and they are useful to anyone else building detection here. There is no server component and no vendor dependency, so nothing breaks for anyone if I stop.

One commitment: I would rather report that the heuristic was too weak than quietly narrow the claim. The evidence that I actually do this is in the README, which now says the fingerprint is a tripwire and not proof of a stable server, because a reviewer told me it read as a safety claim and he was right.

How much money have you raised in the last 12 months, and from where?

$0 raised, no investments no revenue.