ToolFunnel is a zero-dependency MCP and local tool gateway that sits between AI agents and other tools, primarily addressing issues such as MCP servers stuffing all tool descriptions into the model context, causing token bloat, policies being unable to carry across clients, and incompatibility between MCP protocol generations.
Main capabilities: 1. Host your own tools, defined in a JSON registry and implemented with scripts in any language; 2. Forward upstream MCP server tools in a streamlined way, with the ability to filter which ones are exposed, promote some to be visible every turn, and keep them streamlined by default; 3. Streamlined registry, where agents only see brief tool summaries, with full instructions fetched on demand to save tokens; 4. Server-side policy gate, where all server-side execution paths trigger PreToolUse / PostToolUse hooks, with hooks following the Claude Code protocol (event JSON passed via stdin, exit 2 blocks), and fail-closed behavior; 5. Hot-reload configuration via JSON files, a local Web UI, or tf_* management functions, without restarting; 6. Optional JSONL audit logging (disabled by default), recording tool execution and gate allow/deny decisions as well as upstream connection status; 7. Support for mounting, switching, and reconnecting upstream MCPs at runtime.
Build MCP without code: combine several scripts or tools curated from other MCPs, and after disabling the four meta-tools it becomes a normal top-level MCP server, packaged with tf_pack into an npm package installable via npx. The meta-tools are toolfunnel_list_tools, toolfunnel_tool_instructions, toolfunnel_howto, and toolfunnel_run_tool. Each tool has three visibility switches: enabled, hot, and hidden, which can be toggled in real time.
Dual-protocol-generation wrapping: toolfunnel wrap <server> is a single command that makes ToolFunnel a transparent wrapper for an upstream MCP, supporting both old and new protocol generations at the same time, with neither the client nor the server side aware of the intermediate layer, keeping tool names, results, errors, and notifications unchanged, while bridging resource subscriptions, progress tokens, cancellation, and more.
Limitations: It is a single-developer project, and the OAuth 2.1 and Streamable-HTTP implementations are relatively new and less tested; there are no Prometheus/OpenTelemetry metrics, only a toggleable JSONL audit log and /health in-memory counters; because it is not based on the MCP SDK, it needs to be maintained as the MCP specification evolves. Specific installation steps, command details, and complete documentation are not yet provided in this material.
