Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getpioneer.dev/llms.txt

Use this file to discover all available pages before exploring further.

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.

​
Gateway And Workspace Scope

MCP connections belong to a gateway and become available through the current workspace. This keeps environments clean. A work gateway can connect to work systems. A home gateway can connect to personal tools. A sandbox gateway can test new MCP servers before they touch anything important. 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 and their exposed tools can be enabled or disabled. A disabled server can stay configured on the gateway, but agents should not use its tools. Enabled MCP tools can be implicit or not implicit. An implicit MCP tool can be considered automatically when Pioneer decides it is relevant. A not implicit MCP tool stays available, but agents should use it only when you explicitly ask for that MCP capability. Use implicit mode for trusted tools that are safe and useful across many threads. Keep sensitive, destructive, noisy, or rarely needed MCP tools 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. After that, agents can call allowed tools from threads and tasks. 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.