Executor: A Policy-Governed Integration Layer for MCP-Compatible AI Agents

The Problem: Duplicated Integrations Across Every Agent

Every AI agent that talks to external APIs needs its own copy of the integration. Claude Code, Cursor, ChatGPT, and others each require separate API keys, separate MCP server wiring, and separate ideas of what a tool is allowed to do. Executor addresses this by sitting between your agents and your APIs. It lets you configure an integration once, give it credentials once, and set a policy once. Every MCP-compatible agent then shares the same catalog. The target user is a developer or team running multiple agents that need consistent access to the same set of tools, without repeating setup work.

How Executor Works: Integrations, Connections, Policies, and MCP

The core model has four steps. First, you add an integration: an MCP server, an OpenAPI spec, a GraphQL API, or a Google Discovery document. Second, you create a connection, which is an authenticated instance of that integration. One integration can have many connections. Third, you set policies for each tool: always allowed, requires approval, or blocked. The README says sensible defaults are derived from the spec, though it does not explain what those defaults are. Finally, you point your agents at Executor over MCP. The service exposes a streamable-HTTP endpoint at a default port of 4788, and also supports stdio transport. The architecture is a daemon that runs locally or in the cloud, serving a unified tool catalog to any MCP client.

Getting Started: Commands and Configuration

The quick start requires Node.js 20 or later. Install globally with npm, pnpm, bun, or yarn. The README shows: npm install -g executor, then executor install to set up a durable background service, and executor web to open the web UI. For a throwaway run, use executor web --foreground. From the web UI, you add integrations by pasting a URL. The CLI offers the same: executor call executor openapi addIntegration with a JSON payload that includes the spec URL, a namespace, and an optional baseUrl for relative server entries. The baseUrl is important because some OpenAPI documents only have relative paths like /api/v3. To connect an agent, you use the add-mcp package: npx add-mcp http://127.0.0.1:4788/mcp --transport http --name executor, or npx add-mcp "executor mcp" --name executor for stdio. The Connect card in the web UI fills in the exact command for you.

Using Tools: CLI, Resume, and SDK

The CLI provides intent-based search: executor tools search "send email" finds tools by description. You can browse a namespace with executor call github issues --help. To invoke a tool, pass a JSON argument: executor call github issues create '{"owner":"octocat","repo":"Hello-World","title":"Hi"}'. A notable feature is the resume command: executor resume --execution-id exec_123. This handles executions that pause for auth or approval, which is a practical need when policies gate tools. The TypeScript SDK offers a Promise API and an Effect-native API. The README shows creating an executor with plugins, listing tools, and fetching a tool's schema. The plugin system is open to any integration type as long as it can be described with a JSON schema. That is a flexible design, but the README does not document how to write a custom plugin.

Deployment Options and Their Trade-offs

Executor can run in five forms: hosted cloud, CLI, desktop app, Docker self-host, and Cloudflare Worker. The README claims every form exposes the same functionality, just packaged differently. That is a strong claim, and the documentation does not back it up with details. The hosted cloud is the fastest start, with a free tier, and works for cloud agents like ChatGPT that cannot reach a local daemon. The CLI is for headless or server environments. The desktop app is the same runtime as a native app for Mac, Windows, and Linux. Self-hosting with Docker gives full control, while the Cloudflare deployment runs as a Worker. The trade-off is operational: the cloud version requires trusting a third party with your API credentials, while self-hosting puts the burden of securing the daemon on you. The README does not mention how the daemon stores credentials or whether they are encrypted at rest.

Genuine Limitations and Failure Modes

The most obvious limitation is documentation depth. The README is a marketing summary, not an operational manual. It does not specify how policies are enforced, what the derived defaults are, or how approval flows work in practice. It does not explain what happens when an execution pauses for auth: does the user get a notification, or must they poll? The resume command exists, but the trigger conditions are unclear. Another limitation is the dependency on MCP compatibility. If your agent does not support MCP, Executor is useless. The README lists MCP-compatible agents, but not all agents are. Also, the port 4788 is a default, and the daemon picks a free port if busy, which could break hardcoded client configs. The README warns that most MCP clients only load servers at startup, so you may need to restart your client after adding Executor. That is a real friction point in daily use.

Alternatives: Direct MCP Servers vs. Executor

The obvious alternative is to run each MCP server separately and configure each agent to connect to each server directly. That is the status quo Executor is trying to replace. The difference in approach is centralization: with direct MCP servers, you manage multiple endpoints, multiple credential stores, and no unified policy layer. Executor adds a single catalog and a policy engine on top. Another alternative is to build your own integration layer using the MCP SDK directly, but that requires writing code for every integration type and handling auth yourself. Executor's plugin system abstracts that, but it is a black box until you read the plugin API docs. A third alternative is to skip MCP entirely and use agent-specific tool definitions, but that leads back to the duplication problem. The real comparison is between a single, policy-governed endpoint and a patchwork of direct connections.

Maintenance, Licensing, and Upgrade Considerations

The project is MIT licensed, which means you can use, modify, and redistribute it freely, including in commercial products, as long as you preserve the license notice. The repository is active, with releases in August 2026, including v1.6.3 and a graph-slices release for Microsoft Graph. That suggests ongoing development, but the README does not document a migration path between versions. Upgrading could break your integrations or policies, and there is no changelog in the README. The CLI installation via npm makes upgrades as simple as npm update -g executor, but the daemon service may need to be restarted after an upgrade. The documentation does not say whether the daemon auto-updates or whether you must re-run executor install. For self-hosted deployments, you must manage the Docker image or Cloudflare Worker updates yourself. The maintenance cost is moderate: the tool is young, and the documentation is thin, so you will likely need to read the source or ask on Discord for operational details.

Editorial conclusion

Adopt Executor if you manage multiple MCP-capable agents that currently duplicate the same API credentials and tool definitions, and if you need centralized policy enforcement. Skip it if you require a single-agent setup with one-off integrations, or if you cannot tolerate a project whose documentation omits security details, scaling limits, and update procedures. Before adopting, verify the plugin system's support for your custom integration types, confirm the policy defaults match your security needs, and test the Docker or Cloudflare deployment on your infrastructure. The project is actively maintained, with recent releases, but the README alone does not prove production readiness.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes