Skip to content

Wire flowgate into your editor

You install flowgate. You write your gateway.yaml. Now the model in your editor needs to actually see the 2 fixed tools instead of whatever the editor ships with.

Each editor wires it slightly differently. This guide walks each one — Zed, Cursor, Claude Desktop, Claude Code, VS Code.

The editor’s agent panel speaks the Model Context Protocol. It spawns mcp-flowgate serve as a child process, gets the 2 fixed tools (flowgate.query for all reads, flowgate.command for all writes), and the model uses them. Every editor in this guide supports MCP.

Each config below declares flowgate as a single MCP server, pointing at your flowgate.yaml. Merge the snippet into your editor’s config by hand — these files carry your own themes, keybindings, and other servers, so don’t overwrite the whole block.

Add to .zed/settings.json:

{
"context_servers": {
"flowgate": {
"command": { "path": "mcp-flowgate", "args": ["serve"] }
}
},
"agent": {
"default_profile": "write",
"profiles": {
"flowgate": {
"name": "Flowgate",
"tools": {
"read_file": false,
"list_directory": false,
"terminal": false,
"edit_file": false,
"grep": false,
"find_path": false,
"diagnostics": false,
"fetch": false,
"copy_path": false,
"create_directory": false,
"delete_path": false,
"move_path": false,
"open": false,
"save_file": false,
"restore_file_from_disk": false,
"search_web": false,
"thinking": false,
"now": false,
"spawn_agent": false
},
"enable_all_context_servers": false,
"context_servers": {
"flowgate": {
"tools": {
"flowgate.query": true,
"flowgate.command": true
}
}
}
}
}
}
}

That’s two things:

  1. context_servers.flowgate — registers flowgate as an MCP server Zed can spawn.
  2. agent.profiles.flowgate — a custom agent profile that disables all 19 of Zed’s built-in tools (read_file, terminal, etc.) and enables only the 2 flowgate tools. Switching to this profile in the agent panel gives the model exactly the 2 tools, nothing else.

Open the agent panel, pick Flowgate from the profile dropdown at the bottom. The model now sees only governed actions. Switch back to Write when you want raw editor access.

Paste this into .cursor/mcp.json:

{
"mcpServers": {
"flowgate": {
"command": "mcp-flowgate",
"args": ["serve"],
"env": {
"FLOWGATE_CONFIG": "${workspaceFolder}/flowgate.yaml"
}
}
}
}

Restart Cursor. The 2 flowgate tools show up in the agent’s tool list alongside Cursor’s built-ins.

One caveat that Zed users don’t have: Cursor doesn’t let you disable built-in tools at the editor level. The model can still call Cursor’s own file-editing, terminal, and web-search tools alongside flowgate’s. If you want strict “only flowgate” governance in Cursor, enforce it in gateway.yaml — declare all the side-effecting connections (shell, GitHub, etc.) behind flowgate’s connections: proxy with appropriate guards. The editor side stays permissive; the gateway side stays strict.

Merge a snippet into Claude Desktop’s config file, which lives at a platform-specific path:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Linux: ~/.config/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

The snippet shape:

{
"mcpServers": {
"flowgate": {
"command": "mcp-flowgate",
"args": ["serve"],
"env": {
"FLOWGATE_CONFIG": "/absolute/path/to/your/flowgate.yaml"
}
}
}
}

Restart Claude Desktop. Flowgate’s two tools appear in the model’s tool inventory.

If you already have other MCP servers wired into Claude Desktop, merge under mcpServers — add a "flowgate": { ... } key alongside the existing ones. Don’t overwrite the whole mcpServers block; you’d lose your other servers.

Two equivalent ways.

Add a .mcp.json to your project root. Claude Code auto-discovers it on session start:

{
"mcpServers": {
"flowgate": {
"command": "mcp-flowgate",
"args": ["serve"]
}
}
}
Terminal window
claude mcp add flowgate -- mcp-flowgate serve

That registers flowgate in Claude Code’s project-scoped MCP config without touching files directly. Subsequent claude invocations from this project pick it up. To see what’s wired:

Terminal window
claude mcp list

Either path produces the same effect. Pick .mcp.json if you want the config in version control alongside your gateway.yaml; pick the CLI if you’d rather keep MCP wiring out of your repo.

VS Code (via Continue, Cline, or any MCP-client extension)

Section titled “VS Code (via Continue, Cline, or any MCP-client extension)”

VS Code itself doesn’t ship MCP support, but most agent extensions (Continue, Cline, etc.) do. They use the same .mcp.json shape shown above — drop it in the project root and the extension picks up flowgate as an MCP server. Restart the extension. The tools surface in the extension’s agent panel.

A dedicated VS Code extension for gateway.yaml editing (analogous to a language server with hover docs and validation against the V1–V23 cloud) is plausible follow-up work — not shipping with v0.2.

The MCP path above gives the model a tool surface and lets it discover and call tools freely — that’s the surface every editor supports. If instead you want to drive a workflow end-to-end (walking states, routing each delegate: state to a named model, auditing at the workflow level rather than per tool call), that’s the open agentic runtime (flowgate TUI, in the mcp-flowgate-tui crate). Workflows you author here run under both.