A Tool Gateway Can Hold the Keys Without Giving Them to Agents

·https://executor.sh/joelclaw/mcp
articleaimcpagent-toolsinfrastructuresecuritytool-policyjoelclaw

Executor's shared catalog and allow/approve/block boundary could replace duplicated tool wiring across joelclaw's Pi, Claude Code, and Codex clients.

Executor puts one Model Context Protocol endpoint between agents and the APIs they call. Claude Code, Cursor, Codex, and other compatible clients connect once. Behind that endpoint, Executor turns upstream MCP servers, OpenAPI specifications, and GraphQL endpoints into one tool catalog.

The clever bit isn’t aggregation. It moves credentials and policy out of the agent. Executor stores connection credentials, adds them only to upstream requests, and gives each tool one of three policies: allow, require approval, or block. The joelclaw endpoint returns an OAuth bearer challenge without authorization, so the catalog is a protected resource rather than a public tool dump.

This maps cleanly to joelclaw, where several agent clients need access to actions with different blast radii. It’s useful as a reference implementation and possibly as a shared tool boundary. The catch is policy duplication: if joelclaw and Executor both gate the same call, one system must clearly own the final decision.

Key Ideas

  • One streamable HTTP MCP endpoint can expose tools from MCP servers, OpenAPI, and GraphQL without client-specific setup for each integration.
  • Credentials stay inside Executor, while the agent receives tool schemas and results rather than secret material.
  • Per-tool policies make read, approval-bound, and forbidden actions explicit at the gateway.
  • Integrations describe tool catalogs; connections bind those catalogs to authenticated instances.
  • The same open-source TypeScript system can run as a CLI, desktop app, hosted service, Docker container, or Cloudflare Worker.

Links

← All discoveries