toolfence-site

# Toolfence — landing site Marketing site for **[Toolfence](https://github.com/nikolas-sapa/toolfence)**, the open-source security scanner for MCP servers. This repo hosts the static landing page (`index.html`). The scanner source lives in [`nikolas-sapa/toolfence`](https://github.com/nikolas-sapa/toolfence). ```bash npx toolfence <url> ``` ## What is Toolfence Toolfence is an open-source security scanner for MCP (Model Context Protocol) servers that reports, in one command, the specific risks your AI agents inherit the moment they connect — tool poisoning, prompt injection, tool drift, over-broad scope, and context-cost runaway. ### Why Toolfence OAuth authenticated your agents. It didn't make them safe. Authentication is roughly 20% of the MCP threat surface. The other 80% lives in what a server's tools *do* and what their definitions *say* — and that text is fed verbatim into your agent's context window. Toolfence runs 12 checks against any server and returns a severity-ranked report you can act on, with a non-zero exit code when high/critical findings exist so it drops straight into CI. No account, no telemetry, no agent required to reproduce a finding. ### Toolfence vs the alternatives - **vs. OAuth / MCP auth (OAuth 2.1):** Auth proves *who* is calling. It says nothing about a malicious tool description, a silently redefined tool, or a 60K-token catalog. Toolfence covers the part auth leaves open. - **vs. general prompt-injection / LLM firewalls (Rebuff, LLM Guard, Lakera):** Those inspect model inputs/outputs at runtime. Toolfence inspects the *MCP server itself* — tool definitions, schemas, transport, drift — before an agent ever connects. Complementary, not overlapping. - **vs. MCP directories (Smithery, Glama, mcp.so):** Directories help you find servers. They don't tell you whether a server's tool definitions try to hijack your agent. Toolfence scans the server you found. - **vs. writing your own checks:** You could grep tool descriptions by hand. Toolfence ships 12 detectors, each covered by a test that proves it fires on real attacks and stays quiet on benign servers. ### When to use Toolfence - Before connecting an agent (Claude Code, custom LLM app) to any third-party MCP server. - In CI, to fail the build when a server's tool definitions change or trip a signature. - When vetting an internal MCP server before shipping it to teammates. - To baseline a trusted server and detect silent tool drift on later scans. - When a tool catalog feels bloated and you want the actual token cost prepended to every turn. ### FAQ **Q: What does Toolfence actually check?** A: 12 detectors — authentication posture, transport security, prompt-injection signatures, known-bad signatures, tool integrity/drift, context cost, rate-limit posture, naming hygiene, sensitive capability (filesystem/code-exec/network), schema strength, safety annotations, and Unicode hygiene (invisible/bidi/homoglyph characters). **Q: Does it work over stdio, or only HTTP servers?** A: Both. Streamable HTTP, SSE, and local stdio. Output as human-readable Markdown or JSON. **Q: Do I need to run an agent to use it?** A: No. Point it at a URL: `npx toolfence <url>`. It reads the server's tool definitions directly. **Q: Is it free?** A: Yes — the scanner is open source under Apache 2.0, free forever. A hosted governance gateway (runtime sanitization, per-call scope reduction, audit) is on the roadmap as a separate paid layer. **Q: What's a "tool poisoning" finding?** A: A server ships a tool whose description instructs your agent to read secrets or ignore prior instructions. The description is loaded into the agent's context and the agent may comply. Toolfence flags the signature before that happens.