Skip to main content
MCP servers let Pioneer use tools and resources provided by external systems. Pioneer supports servers built for Model Context Protocol, the open standard for connecting AI applications to external systems such as tools, data sources, and workflows. Use MCP when a model needs to query a database, call an internal service, read a documentation system, or use a company-specific integration. The gateway connects to the MCP server, discovers its capabilities, and exposes the allowed ones to agents. Agents do not connect to MCP servers directly. The gateway runs the connection, tracks health, catalogs tools, applies policy, and keeps the integration tied to the selected environment.

​
What MCP is for

Use MCP when there is an existing system you want Pioneer to work with instead of reimplementing it as prompts or shell commands. A local MCP server might expose developer tools on your machine. A remote MCP service might expose internal APIs. A database MCP server might give agents controlled ways to inspect data. A documentation MCP server might let agents search private docs. Ask whether the capability should belong to the gateway and be available across threads or tasks. If it should, MCP is a better fit than pasting instructions into one thread.

​
Workspace scope

MCP connections are installed for the current workspace on the gateway. Workspace scope keeps environments separate. A work workspace can connect to work systems, a personal workspace to personal tools, and a sandbox workspace can test new servers before they reach important systems. Use a separate gateway when the server must run on another machine or security boundary. MCP secrets are scoped the same way. Pioneer keeps visible MCP settings redacted and stores actual secret values, such as env and headers, in the gateway secret store.

​
Enabled and implicit MCP

MCP servers can be enabled or disabled. A disabled server can stay configured on the gateway, but agents should not use its tools. Enabled MCP servers can be implicit or not implicit. An implicit MCP server can have its tools considered automatically when Pioneer decides they are relevant. A not implicit MCP server stays available, but agents should use its tools only when you explicitly select that MCP capability or ask for it. Newly installed MCP servers start not implicit by default. Use implicit mode only for trusted servers whose tools are safe and useful across many threads. Keep sensitive, destructive, noisy, or rarely needed MCP servers not implicit.
MCP tools can affect whatever the MCP server can reach. Test new servers in Supervised mode first, and keep destructive or sensitive servers explicit-only until you trust their behavior.

​
How it feels in use

After you add a server, Pioneer starts or connects to it, reads its catalog, and shows the available tools, resources, templates, and prompts. You decide what should be enabled in the current workspace and whether tools should be implicit. In a thread, use the composer add button and choose Add MCP to attach a whole server or specific tools to the next turn. Selected MCP capabilities appear as chips above the input and on the sent user message. If you select a whole server, Pioneer treats that as the server-level selection for the turn and suppresses duplicate individual tool selections for that server. MCP selections are not pasted into the prompt as plain text. Pioneer turns them into available tools for that turn, and calls still route through the gateway MCP service. Large MCP catalogs are supported, but they are still bounded for predictable execution. Pioneer currently caps materialized catalogs at 512 tools, limits their combined schemas to 3 MiB, and allows up to 16 concurrent MCP calls in one turn. These limits are validated consistently by the gateway and CLI-backed runtimes. For local processes, Pioneer uses stdio. For network services, it uses HTTP.

Connecting MCP Servers

Add stdio or HTTP MCP servers to a gateway.

MCP Catalog

Inspect exposed tools, resources, and health.

​
Further reading

  • MCP Architecture explains installation, runtime supervision, catalogs, policy, and tool binding.
  • Secret Storage explains how MCP env/header secrets are stored.
  • Permission System explains how MCP read and write/unknown tool actions are evaluated and constrained by turn security policy.
  • Tools Architecture explains how MCP tools become model-visible tools during a turn.