Proxy other MCP servers

Exeora can act as an MCP client as well as an MCP server. exeora connect starts the MCP servers configured on the machine, discovers their tools, and publishes them through the same Exeora MCP URL your agent already uses.

The upstream connection stays on your machine. A stdio server runs there as a child process, and a remote Streamable HTTP server is called from there. The gateway stores only the tool catalog, and routes each call back to the connected CLI.

Your MCP servers#

List your servers in mcp.json, next to Exeora's config.json. The shape is the mcpServers object most MCP clients already use, so an existing entry can be pasted in. Each server has either a command (stdio) or a url (Streamable HTTP), never both.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }
    },
    "internal": {
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${INTERNAL_MCP_TOKEN}" }
    }
  }
}

When EXEORA_CONFIG_PATH moves config.json, mcp.json is read from the same directory. Values may reference environment variables as ${NAME}, so secrets stay in the environment. Set "enabled": false to keep an entry without starting it.

A stdio server runs with the project root as its working directory, or with the Git workspace a call names. On Windows, launchers such as npx and uvx are found through PATHEXT, the way a shell finds them.

Project servers#

A project's exeora.toml can switch one of your servers off for that project, which never needs permission because it only narrows what runs:

[mcp.servers.github]
enabled = false

It can also define servers of its own, but that file travels with the repository, and loading it would let anyone who can commit to the project start processes on your machine. So project servers are started only when mcp.json says "trustProjectServers": true, and exeora connect prints a warning naming the servers it skipped. Even when trusted, a project entry never expands ${NAME}: a repository must not be able to send your environment to a URL it chose.

[mcp.servers.docs]
command = "uvx"
args = ["project-docs-mcp"]

A trusted project entry with the same name replaces your entry for that project.

What the agent sees#

Upstream tools are named mcp__server__tool, sanitized to letters, digits, _ and -, and capped at 64 characters, the limit several MCP clients enforce. A name that would be longer, or that would collide with another after sanitizing, is shortened with a stable hash suffix.

Each tool keeps its upstream input schema, annotations and result, including images, structured content and isError. Exeora adds an optional workspace field to route the call to a connected Git workspace. If the upstream tool already owns that name, the routing field is __exeora_workspace instead, and the schema from tools/list always shows which one applies.

On the account MCP URL, a tool may exist in several projects. With one project, its full schema is kept and project is optional. With several, the schema merges their properties and requires project, and each upstream server still validates its own arguments.

Policy and confirmation#

Proxied tools follow the project's policy. Whether a tool changes anything comes from its server's readOnlyHint, and a tool without one is treated as one that does.

• A read_only project runs only proxied tools marked read only.
• A project that asks before changes asks before every proxied tool not marked read only. The question names the server and the tool and previews the arguments.
• The CLI checks the same rule again, against the project's own exeora.toml and the catalog it published itself, before it calls the upstream server.

The tools list and the command allow and deny lists do not apply: they name Exeora's own tools and commands, and which upstream servers exist is decided by your MCP configuration.

Limits and failures#

A project publishes up to 256 proxied tools and 1.5 MB of catalog. Tools past either limit are left out, with a warning. A single call may run for up to 300 seconds.

Servers start in the background, so native tools work from the moment the CLI connects and proxied tools appear once their server answers. A server that fails to start is reported once and retried on a later reconnect, while the others keep working. Restart exeora connect after changing MCP configuration.

This proxies upstream tools. Prompts and resources from another MCP server are not re-published.