I built this because the MCP registry verifies who published a server (namespace auth tied to a GitHub account/domain), but nothing verifies what a server does once you run it. The trust tooling I could find is almost all static analysis, scanning source and metadata. That misses the stuff that only shows up at runtime: a server that connects somewhere unrelated to its job, reads files outside its lane, or changes behavior in a later version after you've already trusted it (the rug-pull case).
So I ran each server in a throwaway Linux container under strace, logging every file open and network connection, with a fake credential seeded in the environment as a canary. Ran it across 70 servers, the 20 most-downloaded on npm plus 50 from the long tail.
67 were clean at startup. 3 make outbound HTTPS calls at boot, before any tool is invoked, all to hosts consistent with what they're for (an exchange integration, a GitHub fetch, some CDN/cloud endpoints), and none read sensitive files or touch the canary. 1 (bullmq-mcp) reads /etc/passwd at startup, which looked alarming until the trace showed it's a standard glibc user lookup (nsswitch.conf then passwd, classic getpwuid), and a follow-up run confirmed the contents never leave the process. Benign.
Honest scope: this only captures startup + idle behavior right now, not individual tool calls, which is where more of the interesting behavior lives. Tool-call tracing and cross-version diffing (to catch rug pulls) are what I'm building next. Repo has the harness, per-server manifests, and the full writeup.
I'd genuinely like feedback on two things: whether the runtime-behavior angle is worth pursuing over just static scanning, and whether anyone would actually want this as a feed their MCP client checks before install.
This gives me a lot of peace of mind. I've been a bit hesitant to spin up too many MCP servers locally when I can't easily tell what permissions they're asking for.
I built this because the MCP registry verifies who published a server (namespace auth tied to a GitHub account/domain), but nothing verifies what a server does once you run it. The trust tooling I could find is almost all static analysis, scanning source and metadata. That misses the stuff that only shows up at runtime: a server that connects somewhere unrelated to its job, reads files outside its lane, or changes behavior in a later version after you've already trusted it (the rug-pull case). So I ran each server in a throwaway Linux container under strace, logging every file open and network connection, with a fake credential seeded in the environment as a canary. Ran it across 70 servers, the 20 most-downloaded on npm plus 50 from the long tail. 67 were clean at startup. 3 make outbound HTTPS calls at boot, before any tool is invoked, all to hosts consistent with what they're for (an exchange integration, a GitHub fetch, some CDN/cloud endpoints), and none read sensitive files or touch the canary. 1 (bullmq-mcp) reads /etc/passwd at startup, which looked alarming until the trace showed it's a standard glibc user lookup (nsswitch.conf then passwd, classic getpwuid), and a follow-up run confirmed the contents never leave the process. Benign. Honest scope: this only captures startup + idle behavior right now, not individual tool calls, which is where more of the interesting behavior lives. Tool-call tracing and cross-version diffing (to catch rug pulls) are what I'm building next. Repo has the harness, per-server manifests, and the full writeup. I'd genuinely like feedback on two things: whether the runtime-behavior angle is worth pursuing over just static scanning, and whether anyone would actually want this as a feed their MCP client checks before install.
This clearly is a copied response from Claude for something like "Summarize RESULTS.md so that i can use it as a comment for HN."
This gives me a lot of peace of mind. I've been a bit hesitant to spin up too many MCP servers locally when I can't easily tell what permissions they're asking for.