Stop Pasting the Same API Keys Into Every Agent You Use

If you've got Claude Code, Cursor, and ChatGPT all wired up to the same handful of services, you already know the drill. Every new agent means re-entering the same credentials, re-adding the same MCP servers, and hoping you remember which tools you'd restricted last time. Executor is an open-source integration layer that tries to fix this by giving you one catalog that every MCP-compatible agent can share.

What It Does

Executor sits between your agents and the services they talk to. You configure an integration once—an MCP server, an OpenAPI spec, a GraphQL API, or a Google Discovery endpoint—along with its authentication and per-tool policies. Then any MCP-compatible agent connects to Executor over MCP and gets access to that same catalog.

The mental model is straightforward. An integration is the definition of a service. A connection is one configured (and optionally authenticated) instance of that integration—and an integration can have many connections. Policies decide what each tool is allowed to do: always allowed, gated behind approval, or blocked outright, with defaults derived from the spec itself.

It runs as a background service you install via npm, and there's a web UI for managing everything. The README also mentions Executor Cloud, a desktop app, and self-hosted options on Docker or Cloudflare. Same functionality, different packaging.

Why It's Cool

• The duplication problem is real, and this actually addresses it. The README puts it well: the same API keys pasted in three places, the same MCP servers wired up again, no shared idea of what each tool is allowed to do. Executor makes integrations, auth, and policies live in one place instead of scattered across each client. That's a small architectural decision with an outsized effect on how much maintenance you're doing.

• Policy per tool, not per integration. This is the part that stands out to me. Rather than a blunt on/off switch for a whole service, you decide tool by tool whether something is allowed, needs approval, or is blocked. And the defaults come from the spec, so you're not starting from a blank page every time you add something new.

• The plugin system is open. First-party support covers MCP servers, OpenAPI, GraphQL, and Google Discovery, but the README notes that if you can describe something with a JSON schema, it can be an integration. That's a nice bit of flexibility—it means the catalog isn't capped at whatever the maintainers got around to building.

• You don't have to run it yourself. Cloud, CLI, desktop, Docker, Cloudflare—the same functionality in different packaging. If you just want to try it, there's nothing to install. If you need it headless on a server, that's covered too. The free tier on Cloud is a low-friction way to see whether the model fits how you work.

How to Try It

The fastest path is Executor Cloud: sign in, add an integration, and point your agents at the hosted MCP endpoint. Nothing to install.

If you'd rather run it locally, you'll need Node.js 20 or higher:

npm install -g executor   # or: pnpm add -g / bun add -g / yarn global add
executor install          # install the durable background service
executor web              # open the web UI in your browser

The executor install command keeps the service running across restarts. If you just want a throwaway foreground runtime, use executor web --foreground instead. From the web UI, add your first integration and connect an agent.

There's also a setup prompt in the docs you can paste directly into Claude, Cursor, or any MCP-capable agent—it'll walk through choosing how to run Executor, installing it, connecting over MCP, and getting a first integration working end to end. That's a nice touch for anyone who'd rather delegate the fiddly parts.

The full model is documented under Concepts, and the source lives at github.com/usefulsoftwareco/executor.

Final Thoughts

Executor is aimed at anyone juggling more than one agent—which, at this point, is most people doing serious work with these tools. The value proposition is simple: configure once, share everywhere, keep the policies in one place. If you're only using a single agent, you probably don't need this yet. If you're past that point, the duplication tax is real, and this is a reasonable answer to it. Worth a look, especially since the Cloud tier lets you evaluate the whole thing before committing to a local install.

Follow @githubprojects for more developer tools and open source projects.