MCP

MCP support does not exist in Forge 0.1.0. There is no configuration to write and no flag to pass. This page explains what is there instead, and where the work will land - it is not a description of something you can use today.

What exists today

Tools reach the model through a single registry. Each entry has a name, a typed schema, a risk level, and a handler; the agent loop only ever sees that interface, and the permission policy decides on the risk level rather than on where a tool came from.

$ forge tools --json

That list is the complete set of what the model can call. See Tools for what is in it.

Where MCP plugs in

An MCP server exposes tools over a protocol. Because the registry already abstracts a tool from its implementation, adding MCP means translating a server's advertised tools into registry entries at startup - not changing the loop, and not adding a second permission path.

• Configured servers are contacted when the session starts, and their tools registered.
• Each imported tool gets a risk level, so approval modes apply to it exactly as they do to a built-in.
• A server that is unreachable degrades to its tools being absent, not to a failed start.

What to do in the meantime

Most of what people reach for MCP for, the shell tool already covers. If a capability has a CLI, Forge can use it - that is the whole point of a terminal-native agent.

$ forge "use gh to find the open issue about timeouts, then fix it"$ forge "check the staging logs with our logs CLI and find the 500s"

Install the CLI, make sure it is authenticated, and mention it in the task. It is less tidy than a declared tool, and it works now.

Tracking it

MCP support is on the roadmap without a date attached. Progress is visible in the repository, and there is no private build ahead of what is public.

• Issues - request it, or say what you would connect first.
• Releases - where it will show up when it exists.