Skip to main content
MCP servers let Pioneer reach tools and resources that live outside Pioneer. 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. If a model needs to query a database, call an internal service, read from a documentation system, or use a company-specific integration, MCP is one way to make that available. The gateway connects to the MCP server, discovers what it exposes, and lets agents use the allowed pieces. Agents do not connect to MCP servers directly. The gateway is the runtime in the middle. That is useful because the gateway can track health, catalog tools, apply policy, and keep the behavior tied to the environment you chose.

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. The practical question is simple: should this capability belong to the gateway and be available across threads or tasks? If yes, MCP is probably a better fit than pasting instructions into one thread.

Workspace Scope

MCP connections are installed for the current workspace on the gateway. This keeps environments clean. A work workspace can connect to work systems. A personal workspace can connect to personal tools. A sandbox workspace can test new MCP servers before they touch anything important. Use a separate gateway when the MCP server must run on a different machine or security boundary. MCP secrets are scoped the same way. Redacted install data and secret refs live in the gateway database, while actual secret values from env and headers live in that gateway’s keystore.

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. Combined with the current lack of tool sandboxing, you should test new MCP servers carefully.

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 rendered as prompt prose. They materialize as model-visible tool definitions in the provider request, and calls still route through the gateway MCP service. 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.