Agent & MCP Integration

Chalie speaks MCP in both directions. Inbound, it runs an MCP server so other agents — coding assistants, your own scripts, anything MCP-aware — can hand a task to Chalie and get an executive-assistant answer back. Outbound, it’s an MCP client: connect a remote server and every tool that server exposes becomes a Chalie tool, discovered and governed exactly like a built-in ability. This page covers both directions and how they wire into the runtime.

Inbound: other agents talk to Chalie

Chalie exposes a single MCP tool to the outside world — talk_to_chalie. An external agent calls it with a message and gets Chalie’s full reply, with all of Chalie’s tools, memory, and context behind it. The agent doesn’t drive Chalie’s tools directly; it asks Chalie in natural language, and Chalie figures out the rest.

The server is a daemon worker registered at boot, built on FastMCP. It runs over Streamable HTTP on its own dedicated port — 8462 by default, separate from the main web interface — and is enabled out of the box. The port is configurable from the Brain dashboard’s MCP Server tab.

Authentication

Every request must carry a bearer token. Middleware validates the Authorization: Bearer <token> header against Chalie’s token store on each call, rejecting a missing, malformed, or revoked token with a 401 before it reaches the tool. Chalie generates a token automatically on first boot if none exists; you retrieve or regenerate it from the MCP Server tab. The same token mechanism backs Chalie’s REST API, so an inbound agent is authenticated the same way every other client is.

Connecting an agent

Point any MCP-compatible client at the server’s /mcp path with the token:

{
  "mcpServers": {
    "chalie": {
      "type": "http",
      "url": "http://<CHALIE_HOST>:8462/mcp",
      "headers": { "Authorization": "Bearer <TOKEN>" }
    }
  }
}

Once connected, the client sees one tool — talk_to_chalie — with these parameters:

agent_name and project_or_task_name are validated to a safe 1–100 character set; bad input comes back as a clear, itemised error rather than a silent failure. Set loop_in_human: true when the exchange involves a decision the user should know about or touches their personal data, so Chalie surfaces it instead of handling it quietly.

What happens inside

A talk_to_chalie call doesn’t take a special path. It builds an external-agent channel config and runs the message through the same turn processor that every chat message uses — the one runtime described in the Architecture Overview. The only thing that differs is the channel, and the channel changes one thing that matters for safety: the external-agent channel has no human at a prompt, so any tool whose policy is ask is automatically treated as deny. An inbound agent can ask Chalie to do anything, but it can never trigger a confirmation no one is there to answer — the same guarantee described in Tools & Abilities. This is the conservative side of agent-to-agent: Chalie does the reasoning and answers, but it won’t take a gated action on a faceless caller’s say-so.

Outbound: Chalie uses external tools

The reverse direction lets Chalie borrow capabilities. Connect a remote MCP server — a task tracker, a home-automation bridge, an internal company tool, another agent — and its tools fold straight into the pool Chalie searches when deciding how to help. You never name those tools yourself; you just ask Chalie, and discovery finds the right remote tool the same way it finds a built-in one.

You add a connection two ways: from the Brain dashboard’s MCP tab (the Outbound section), or simply by asking Chalie in conversation — “connect to the MCP server at https://mcp.example.com/mcp and call it task-tracker.” Conversational management runs through the MCP manager ability, so listing, enabling, disabling, and testing connections all work by just asking.

How remote tools behave like native ones

This is the payoff of Chalie’s uniform tool model: a remote tool isn’t a second-class citizen. Each remote tool surfaces under an _mcp_<server>_<tool> name, and when the model calls it, a synthetic proxy ability wraps the call. That proxy is a real member of the ability hierarchy, so an MCP call takes the exact same dispatch path as a built-in tool — match, policy gate, execute, record — rather than a parallel one. The remote tool’s own schema becomes the proxy’s parameters, fetched and cached from the server.

Concretely, that means:

• Discovery. Remote tools are embedded into the same search index, so find_tools ranks them alongside built-ins.
• Policy. Remote tools pass the same permission gate. A remote tool takes real action somewhere you don’t control, so by default it sits at ask — Chalie confirms with you before running it — and you can adjust that per tool in the policy manager.
• Results. Remote outcomes are mapped onto the standard result contract, including stable error codes — mcp-unreachable when a server doesn’t respond (named so you know which one), mcp-unknown-tool when no enabled server offers the tool, and mcp-tool-error when the remote tool itself fails. A remote failure is never dressed up as success.

Keeping connections fresh

A background heartbeat worker, also registered at boot, pings every enabled remote server on a fixed interval. On each cycle it reconnects over the MCP transport, re-syncs the server’s tool list, and flips its status to online or offline — one bad server never blocks the others. So a server that drops offline and comes back is picked up on its own, and newly added tools appear without you doing anything.

Two directions, one model

The symmetry is the point. Inbound, Chalie is a callable agent behind a single conversational tool, sandboxed by the no-human-no-gated-action rule. Outbound, external tools become Chalie’s tools, governed by the same discovery, dispatch, and policy machinery as everything built in. Neither direction needs special-case plumbing — both ride the one turn processor and the one tool pipeline. For how a turn actually assembles and runs, see Message Flow; for how Chalie keeps context between these exchanges, see Memory & Cognition.