---title: MCP Proxydescription: "Executor is one MCP endpoint in front of all your integrations: connect once, and every agent gets the same catalog with shared auth and policies."---Executor sits between your agents and your tools as a single MCP endpoint. Youragents connect to Executor; Executor connects out to your integrations andre-exposes them as one catalog. Every tool call passes through the proxy, which iswhere auth and policy live.## Why proxy through Executor- **One endpoint, every agent.** Point Claude Code, Cursor, ChatGPT, or your own SDK at the same Executor endpoint instead of configuring each tool in each client.- **Credentials stay out of the agent.** A [connection](/concepts/connections)'s credentials are stored by Executor and attached to the upstream call. The agent runs in a sandbox and never sees them.- **Per-tool policies.** Every call is governed by a [policy](/concepts/policies): allow, require approval, or block.- **Mix [integration types](/concepts/integrations).** Upstream MCP servers, OpenAPI specs, and GraphQL endpoints all show up in the same catalog.## How it works```mermaidflowchart LR A[Your agents] -->|MCP| E[Executor] E -->|MCP| M[Upstream MCP servers] E -->|HTTP| O[OpenAPI APIs] E -->|HTTP| G[GraphQL endpoints]```Agents speak MCP to Executor. For each tool call, Executor picks the rightintegration, attaches that connection's credentials to the upstream request,enforces the tool's policy, and returns the result. The agent only ever talks toExecutor, and the credentials never reach it.## Proxy an upstream MCP serverAdd an MCP server as an [integration](/concepts/integrations) and its tools joinyour catalog alongside everything else. Create a [connection](/concepts/connections)to it (with credentials if it needs them), and it becomes reachable through your oneExecutor endpoint, governed by the same policies as the rest of your tools.This is the core of the proxy: your agents keep talking to a single endpoint whileyou add, swap, or remove upstream servers behind it, with no client-side change.## Connect your agentsAgents connect to Executor's MCP endpoint. The exact command depends on how you runExecutor:- **Local:** see [CLI](/local/cli) for `executor mcp` and the `add-mcp` command.- **Hosted:** see [Executor Cloud](/hosted/cloud), or self-host on [Docker](/hosted/docker).Once a client is connected, every integration you add to Executor appears in thatagent automatically.## Search and invoke modeAdd `?mode=passthrough` to your MCP endpoint, or enable **Search and invoke**in the Connect card. This mode exposes four discovery and invocation tools:- `integrations`: list connected accounts with integration descriptions, account labels, and their last recorded health. Results are paginated, with one item per account. Health is not checked again by this call.- `skills`: list this server's guides, or read `skills({ name: "search-invoke" })`.- `search`: find tools and read their JSON input schemas. Use the exact `integration`, `owner`, and `connection` fields from `integrations` to select an account.- `invoke`: call the exact tool ID from search with JSON arguments.For example, call `integrations({})`, then`search({ query: "create issue", integration: "github", owner: "org", connection: "main" })`using the account names returned by your server. Call `invoke` with the matchingresult's `id` and arguments that follow its `inputSchema`.Both `integrations` and `search` return `items`, `total`, `hasMore`, and`nextOffset`. To get another page, repeat the same query and filters with`offset: nextOffset`. This pagination finds tools and accounts; each upstream APIhas its own pagination for records.The tool list stays small as you add integrations. Input schemas are loaded onlyfor matching search results. Your client handles approval for `invoke`, andworkspace block policies still apply. This mode does not expose a general code execution tool. Artifacts remainavailable unless you disable them with `artifacts=false` or the Artifacts toggle.Use `skills({ name: "create-artifact" })` for the guide to building artifactsafter discovering data with search and invoke.
---
title: MCP Proxy
description: "Executor is one MCP endpoint in front of all your integrations: connect once, and every agent gets the same catalog with shared auth and policies."
---
Executor sits between your agents and your tools as a single MCP endpoint. Your
agents connect to Executor; Executor connects out to your integrations and
re-exposes them as one catalog. Every tool call passes through the proxy, which is
where auth and policy live.
## Why proxy through Executor
- **One endpoint, every agent.** Point Claude Code, Cursor, ChatGPT, or your own
SDK at the same Executor endpoint instead of configuring each tool in each client.
- **Credentials stay out of the agent.** A [connection](/concepts/connections)'s
credentials are stored by Executor and attached to the upstream call. The agent
runs in a sandbox and never sees them.
- **Per-tool policies.** Every call is governed by a [policy](/concepts/policies):
allow, require approval, or block.
- **Mix [integration types](/concepts/integrations).** Upstream MCP servers, OpenAPI
specs, and GraphQL endpoints all show up in the same catalog.
## How it works
```mermaid
flowchart LR
A[Your agents] -->|MCP| E[Executor]
E -->|MCP| M[Upstream MCP servers]
E -->|HTTP| O[OpenAPI APIs]
E -->|HTTP| G[GraphQL endpoints]
```
Agents speak MCP to Executor. For each tool call, Executor picks the right
integration, attaches that connection's credentials to the upstream request,
enforces the tool's policy, and returns the result. The agent only ever talks to
Executor, and the credentials never reach it.
## Proxy an upstream MCP server
Add an MCP server as an [integration](/concepts/integrations) and its tools join
your catalog alongside everything else. Create a [connection](/concepts/connections)
to it (with credentials if it needs them), and it becomes reachable through your one
Executor endpoint, governed by the same policies as the rest of your tools.
This is the core of the proxy: your agents keep talking to a single endpoint while
you add, swap, or remove upstream servers behind it, with no client-side change.
## Connect your agents
Agents connect to Executor's MCP endpoint. The exact command depends on how you run
Executor:
- **Local:** see [CLI](/local/cli) for `executor mcp` and the `add-mcp` command.
- **Hosted:** see [Executor Cloud](/hosted/cloud), or self-host on
[Docker](/hosted/docker).
Once a client is connected, every integration you add to Executor appears in that
agent automatically.
## Search and invoke mode
Add `?mode=passthrough` to your MCP endpoint, or enable **Search and invoke**
in the Connect card. This mode exposes four discovery and invocation tools:
- `integrations`: list connected accounts with integration descriptions, account
labels, and their last recorded health. Results are paginated, with one item per
account. Health is not checked again by this call.
- `skills`: list this server's guides, or read `skills({ name: "search-invoke" })`.
- `search`: find tools and read their JSON input schemas. Use the exact
`integration`, `owner`, and `connection` fields from `integrations` to select an
account.
- `invoke`: call the exact tool ID from search with JSON arguments.
For example, call `integrations({})`, then
`search({ query: "create issue", integration: "github", owner: "org", connection: "main" })`
using the account names returned by your server. Call `invoke` with the matching
result's `id` and arguments that follow its `inputSchema`.
Both `integrations` and `search` return `items`, `total`, `hasMore`, and
`nextOffset`. To get another page, repeat the same query and filters with
`offset: nextOffset`. This pagination finds tools and accounts; each upstream API
has its own pagination for records.
The tool list stays small as you add integrations. Input schemas are loaded only
for matching search results. Your client handles approval for `invoke`, and
workspace block policies still apply. This mode does not expose a general code execution tool. Artifacts remain
available unless you disable them with `artifacts=false` or the Artifacts toggle.
Use `skills({ name: "create-artifact" })` for the guide to building artifacts
after discovering data with search and invoke.