MCP servers: tools that coding agents can call

The protocol

The Model Context Protocol is an open standard for connecting AI applications to tools and data. An MCP server publishes tools with typed inputs; a client, such as a coding CLI, lists them for the model and relays the model's calls. A local MCP server usually runs as a child process of the client and talks over standard input and output.

The benefit is reuse: one implementation works with every client that speaks the protocol. The protocol also allows remote connections over HTTP, while DevFlow's configuration uses the local kind.

What DevFlow runs

DevFlow configures figma-developer-mcp, pinned at version 0.13.2, so agents can read design context from figma.com links in a task description. The version is pinned in one place, and a test keeps every image in step with the pin. A comment in the production Dockerfile records why: an unpinned upgrade once changed agent behaviour silently.

The package is added to a run's OpenCode config only when the workspace has stored a FIGMA_API_KEY through a card in workspace settings. The config names an environment variable instead of the key, and that variable is filled from the stored, encrypted key.

Per-role access

A globally registered MCP server would expose its tools to every role. DevFlow prevents that in the per-role agent file, which carries an entry allowing the figma* tool pattern for planning and the implementer and denying the pattern for all other roles.

The entry is written for every role even when no MCP server is registered, because an entry for an absent server is inert. When a run uses the deny-all permission set, such as the one-shot output repair, the pattern is denied as well.

Those two roles are the ones that turn a design link into a plan and then into code. This MCP server only reads design data, so planning and the implementer gain no write access through it.

Inside agent containers

In container mode, the runtime volume bundles Node and the same pinned package, so the package starts inside the container exactly as on the host. The API hosts the package needs are on the egress allowlist, and the key reaches the container through its environment file.

Adding more

Further MCP servers would follow the same pattern: registered per run when their credential exists, gated per role in the agent file and pinned to a version.