On this page

MCP in Commander

The Model Context Protocol is how AI clients and tool servers talk to each other. Commander sits on both sides of it.

Inbound: a chat client operates Commander

The commander-mcp gateway publishes Commander at <commander origin>/mcp. Claude (web or desktop), ChatGPT and any client that speaks Streamable HTTP signs in once through the gateway's own OAuth server, ticks the scopes it should have, and then operates Commander through fifteen umbrella tools - projects, sessions, transcripts, artifacts, personas, git, deploy, workboard, usage, health, settings, access, plus search and fetch - with every call audited.

Access is governed by three things that must all agree: the scope the person granted, the phase the operator enabled on the instance (0 read-only, 1 writes, 2 session control), and the role the operator assigned to the connector (visitor, editor, operator, admin). Production stays read-only by policy.

Outbound: Commander hands connections to its agents

When Commander launches an agent, the MCP broker resolves that agent's bindings - the Library/Ontology, Lighthouse, GTM and Auth servers, and any integration the operator has connected - into a per-session configuration file, and revokes the tokens when the session ends. Personas name which servers an agent may reach; no binding stores a credential. The agent-facing description of this is on the Commander MCP skill page.

Where things live

you want to…go to
connect Claude or ChatGPTConnect a chat client
see which tool does what, and what a role may doServices
turn the gateway on, set phases, tune limitsSettings → Advanced → MCP gateway (described on the Services page)
give a connector more than read accessthe access umbrella (grant), or the Password Vault's admin-role notes on the Services page
let an agent use an external MCP servera persona's MCP bindings (Application page)

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →