Connect any agent to everything.

Executor is an MCP gateway. Anything that speaks MCP, like Claude Code, Cursor, or Codex, points at one endpoint and reaches every tool you connect.

Claude Code

Cursor

Codex

SentryOpenAPI

GitHubGraphQL

LinearMCP

Read docs

Wiring tools to agents is fiddly, per-client, and easy to get wrong. Executor makes every tool, from any protocol, look the same: one name, one input schema, one output schema, so any agent can call any of them the same way.

Context efficiency

Thousands of tools, no bloat.

Connect everything you use and Executor still shows the model a single tool. It searches your catalog and loads a tool's schema only when the code actually calls it, so the prompt never balloons.

Context window

Lower is better

Without Executor1,640 tools · ~278,800 tok

With Executor1 tool · ~1,044 tok

Without Executor

1,640 tools · ~278,800 tok

"You are a helpful assistant.

Your tools are:

createIssue()
listPullRequests()
mergePullRequest()
createRelease()
addLabels()
createBranch()
getCommit()
// + 713 more GitHub tools
createCharge()
createCustomer()
createRefund()
listInvoices()
createSubscription()
capturePaymentIntent()
listPayouts()
// + 503 more Stripe tools
createIssue()
transitionIssue()
addComment()
assignIssue()
listSprints()
createProject()
searchIssues()
// + 233 more Jira tools
listIssues()
resolveIssue()
listEvents()
getProject()
muteIssue()
createRelease()
listAlerts()
// + 163 more Sentry tools
..."

With Executor

1 tool · ~1,044 tok

// the only tool your client sees: "execute"

Execute TypeScript in a sandboxed runtime with access to
configured API tools.

## Workflow

1. const { items } = await tools.search({ query });
2. const path = items[0]?.path;
3. const details = await tools.describe.tool({ path });
4. const result = await tools[path](input);

## Available connection prefixes

- github.org.main: Production GitHub
- stripe.org.main: Live Stripe account
- jira.org.main: Team Jira
- sentry.org.main: Production Sentry

What you get

The model reasons. Executor handles the rest.

One tool shape

MCP, OpenAPI, GraphQL, or a custom integration. Under the hood they all become a tool name, an input schema, and an output schema.

Call it any way

Today it is a code-mode MCP. It could just as well be the Executor CLI, a one-off script, a gen-UI dashboard, or a reusable workflow. Same tools, every surface.

Coming soon

Trace every call

One place to see every run and tool call. Audit any decision after the fact.

run_7421 1.42s

sentry.getIssue 184ms

github.searchCode 391ms

linear.createIssue 612ms

Set up once, whole team has it

Per-user credentials and shared ones. No onboarding ritual, no toggling MCPs on and off mid-task.

Destructive actions pull you back in

Executor keeps the semantics it imported: GET vs DELETE for OpenAPI, destructiveHint for MCP, mutations for GraphQL. Agents auto-run the safe stuff and ask before the rest.

Sandboxed execution

Tool calls run in an isolated JavaScript sandbox. Secrets are injected host-side at call time and never enter the sandbox heap, so the agent and model never see a raw token.

Why we built it

Your agent should be able to reach your company's resources in a way that isn't scary. Most setups make you choose between locked down and useless, or wide open and risky.

Executor doesn't care what you add. Once a tool is in that one shape, a name and two schemas, you can call it however you want and the same guardrails apply everywhere. That is the whole idea: make the safe path the easy path.

Get started

Pick your path.

Cloud

executor.sh/cloud

Hosted Executor. Auth, sync, policies, and your whole team online in five minutes. Free tier to start.

Try Cloud →

Desktop

Mac · Windows · Linux

A native app that runs entirely on your machine. Your integrations, credentials, and sessions never leave the device. MIT licensed.

Download for Mac Download for Mac (Intel) Download for Windows Download for Linux

CLI

npm i -g executor

Run Executor as a background service and drive it from your terminal. Best for headless and server environments. MIT licensed.

Read the docs →

View source →

FAQ

Where does my code run, and what touches my credentials?

Tool calls run in an isolated JavaScript sandbox. Credentials are resolved host-side at call time and injected into the outbound request only. They never enter the sandbox heap, the code your agent wrote, the agent, or the model.

Can the agent or the model ever see a raw token?

No. Secrets stay host-side by design. The sandbox calls a tool by name; Executor attaches the credential to the real request outside the sandbox, so a token is never present in anything the model can read.

What can call Executor?

Any MCP client (Claude Code, Cursor, Codex, and others), the Executor CLI, or a native client you drop in. Because tools share one shape, the calling surface is interchangeable.

How does it know what is safe to auto-run?

Executor preserves the semantics of whatever it imported: GET vs DELETE for OpenAPI, destructiveHint for MCP, and mutations for GraphQL. That tells the agent what it can run on its own and what should pull you back into the loop.

Is it open source? Can I self-host?

Yes. Executor is MIT licensed and built on the SDK we publish to npm. Run the desktop app locally, self-host the server, or use the hosted cloud. Same code paths, different deployment.

Pricing