Your company blocked an MCP server. Good.

It goes like this: you add an MCP server to Cursor or Claude Code, it works great for an afternoon, and the next morning it's greyed out — your company's admin policy blocked it. Before you get annoyed at IT, consider what they're looking at. An MCP server is arbitrary code, often fetched and executed on demand with npx, running inside the same agent loop that reads your codebase. Some of them make network calls to companies nobody in the building has heard of. Blocking that by default isn't paranoia. It's the job.

The problem isn't that companies review MCP servers. It's that most MCP servers give reviewers nothing to review — no egress documentation, no data-flow statement, no way to check what the package actually does short of reading minified output on npm. When there's nothing to evaluate, the only safe answer is no.

The four questions any MCP server should answer

If you're the admin — or the developer writing the approval request — these four questions separate a reviewable tool from an unreviewable one:

1. What code runs? Is the source public and buildable, or are you trusting an opaque binary? How many dependencies come along for the ride, and do any of them run install-time scripts?
2. What network egress does it make? A legitimate server can list every host it contacts, exhaustively. If the vendor can't produce that list, the firewall team can't write an allow rule, and the review stalls right there.
3. What data leaves the machine? Not the marketing answer — the mechanical one. Which tool calls transmit what, where does it land, who are the sub-processors, and how does deletion actually work?
4. What does it touch locally? Does it write files outside its own data directory? Modify configs? Anything a reviewer would find surprising in a diff two weeks later should be disclosed up front, with an off switch.

How threadctx answers them

We wrote a page that answers all four in one place — threadctx.dev/security — because our whole product runs inside exactly this trust boundary. The short version: the client is MIT-licensed and public on GitHub with one runtime dependency and no install scripts; local mode makes zero network calls; cloud mode contacts exactly one host (threadctx.dev); what transits is short agent-written notes, never source code; and the one local write it performs (adding a memory instruction to your repo's agent rule files) is documented, idempotent, and disabled by a single environment variable.

That page also includes a copy-pasteable approval request, because the person who hits the block is rarely the person who can lift it. If your admin blocked threadctx, you don't need to write the justification yourself — send them this and let them hold us to it.

And if you're evaluating any MCP server — including ours — and the vendor can't answer the four questions above in writing, that silence is the answer.