Skip to main content
MCP (Model Context Protocol) lets Comis agents use tools exposed by external servers. Comis does not bundle MCP servers; you choose, configure, and operate the servers your agents may access.
A stdio MCP server runs as a local process and is not a security boundary. Vet the server and its installation command, grant only the credentials it needs, and prefer a pinned package or executable from its publisher.

​
How MCP works in Comis

  • Comis connects to enabled servers when the daemon starts. One failed server does not prevent the daemon or other MCP servers from starting.
  • Tools are discovered from each connected server. Comis tracks them as mcp:server-name/tool-name and exposes the LLM-safe callable name mcp__server-name--tool-name to agents.
  • Only tools from currently connected servers enter the agent tool set. They disappear while a server reconnects and return after discovery succeeds.
  • An involuntary disconnect, keepalive failure, or repeated client error starts automatic reconnection. The default is up to five attempts with jittered exponential backoff; an explicit disconnect is not retried.

​
Configure a server

1

Store any required credential

Secret names must start with an uppercase letter and otherwise use only uppercase letters, digits, and underscores. This command opens a hidden prompt and stores the value in the configured credential backend, which is encrypted by default:
See Secrets Management for non-interactive input and storage modes.
2

Add an array entry to config.yaml

integrations.mcp.servers is an array. Every entry needs a unique name and the fields required by its transport.
Replace the command and arguments with the server publisher’s instructions. Comis resolves ${MCP_SERVICE_TOKEN} through its secret manager when loading the configuration; the secret value does not need to appear in the YAML.
3

Restart and verify

Configuration-file entries are loaded at daemon startup.
You can also inspect servers in the web UI under MCP Servers.

​
Transports

maxConcurrency overrides the transport default. For stdio, keep the default unless the server explicitly supports parallel tool calls. Comis can infer stdio from command or http from url when transport is omitted, but setting it explicitly makes shared configuration easier to review.

​
Remote server example

Use http for current remote servers. Custom headers are supported by http and sse; they are ignored for stdio.
Use sse only when the server requires the legacy transport:

​
Secret references

Use ${UPPERCASE_NAME} anywhere an MCP env or headers string needs a stored value. The same syntax can be embedded in a larger string, such as the Authorization header above. A missing reference is reported instead of starting the server with an unresolved placeholder. For stdio servers, Comis passes a scrubbed baseline environment plus the explicit env entries in the server configuration. It does not copy every daemon environment variable into the child process.

​
Operate connections

The CLI exposes the live MCP connection state:
Additional lifecycle commands are intentionally distinct: Agents with admin trust can use mcp_manage for list, status, connect, disconnect, and reconnect. Connection-changing actions pass through the approval gate. A newly connected server’s tools become callable on the next message because the active tool set is fixed for the current turn. See the configuration reference for MCP’s place in the broader Comis configuration.

Config Reference

MCP configuration structure and core fields

Secrets Management

Store and reference credentials

Tool Policy

Control which tools agents may use