By Flavio Copes

A look at Executor, an open-source, local-first layer that gives your AI agents one shared catalog of tools, with shared auth and built-in safety rules.

~~~

If you use AI coding agents, you’ve felt this. Every agent wants its own tool setup.

You add an MCP server to Cursor. Then you add it again to Claude Code. You paste a huge tool definition into a chat and watch it eat your context. Or you give the agent broad shell access and hope for the best.

Executor is a fix for all of that. It’s one place where you connect your tools, and then every agent can use them. It’s open source, built by Rhys Sullivan.

The problem it solves

Agents are only as useful as the things they can reach: your GitHub, your database, your Linear, your internal APIs.

Connecting them today is messy. Each agent has its own config. Each tool is wired up separately. Big tool catalogs waste tokens because every definition rides along in the prompt. (I built a free context window fit tool that shows how much of a model’s context your prompt stack eats up.) And handing an agent free rein over your systems is, in Executor’s own words, scary.

Executor turns this into one shared layer that sits between your agents and your tools.

What Executor is

Think of Executor as a single catalog of everything your agents can do. You add your tools once, and every agent points at the same catalog, with the same logins and the same safety rules.

The clever part is how it treats those tools. You can add an MCP server, an OpenAPI REST API, or a GraphQL endpoint. Under the hood, Executor turns all of them into the same shape: a tool name, an input schema, and an output schema.

Once everything looks the same, your agent doesn’t need to care where a tool came from. A GitHub API, a Linear MCP server, your own GraphQL backend, they’re all just tools it can call.

How it works

The flow is short:

1. You run Executor locally. It starts a small daemon with a web UI.
2. You add a source: paste a URL for an MCP server, an OpenAPI doc, or a GraphQL endpoint.
3. Executor detects the type, indexes all the tools inside it, and handles the auth.
4. Your agent calls those tools through Executor.
5. If a tool needs a login or some input, execution pauses, opens a local prompt, and then resumes.

Start it with the CLI:

npx executor web

That gives you a local web UI at http://127.0.0.1:4788. Open it, click “Add Source,” paste a URL, and your tools are in.

Here’s the idea I like most.

Instead of stuffing every tool definition into the prompt, the agent writes a little TypeScript that calls only the tools it needs. Executor exposes everything as a typed tools.* runtime, so a task looks like code:

const issues = await tools.linear.listIssues({ assignee: 'me' })
const open = issues.filter((i) => i.state === 'open')

The agent discovers what’s available, pulls in just those tools, and runs real code against them. No giant manifest riding along in context, no guessing at raw HTTP calls.

It can also search the catalog by intent, so it finds the right tool instead of carrying all of them:

executor tools search "create a GitHub issue"

It knows what’s safe and what’s not

This is the part that makes letting an agent loose less scary.

When Executor imports a source, it keeps the meaning of each action. A GET in an OpenAPI doc is a read. A DELETE is destructive. MCP tools carry a destructiveHint. GraphQL mutations change things.

So Executor can tell the agent what it’s allowed to run on its own and what should stop and ask you. You set a policy like “auto-approve reads, pause on writes,” and the agent works autonomously on the safe stuff while pulling you back in for anything risky.

It treats agent tool use as a permission problem, which is exactly the right way to think about it.

Secrets stay yours

Tool calls run in a JavaScript sandbox. The agent can use your secrets to make a call, but the secrets themselves stay local, in your system keychain. They don’t get pasted into prompts or shipped off somewhere.

That local-first stance runs through the whole thing. In the desktop app, your sources, secrets, and sessions all stay on your machine.

Built for a team

Once a tool is set up, it doesn’t have to be set up again by everyone else.

Executor supports shared credentials and per-user ones, so you configure your company’s sources once and the whole team’s agents can reach them. No onboarding ritual, no toggling MCP servers on and off mid-task.

Two ways to run it

• Local. A native app for Mac, Windows, and Linux, or the executor CLI. Everything stays on your machine. MIT licensed.
• Cloud. A hosted version with auth, sync, policies, and your team online in a few minutes. There’s a free tier.

Either way it’s open source, built on an SDK they publish to npm. And because it speaks MCP, you point any MCP-compatible agent at it, Cursor, Claude Code, Codex, and they all share the same catalog.

My take

I’ve been writing about a lot of agent frameworks lately. Executor is solving a different, and honestly underrated, piece of the puzzle.

Frameworks help you build an agent. Executor is about connecting the agents you already use to the tools you already have, safely, in one place, without redoing it for every tool and every agent.

The reads-versus-writes safety model is the detail that stands out. It’s the difference between an agent you babysit and one you can actually let work.

You can try it at executor.sh, and the code is on GitHub.

~~~

Related posts about ai: