Praxec

Wire praxec into your editor

Wire praxec as an MCP server into Zed, Cursor, Claude Desktop, Claude Code, and VS Code (via Continue/Cline). Copy-paste config for each editor.

You install praxec. 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.

How an editor talks to praxec

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

Each config below declares praxec as a single MCP server, pointing at your praxec.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.

Zed

Add to .zed/settings.json:

{
  "context_servers": {
    "praxec": {
      "command": { "path": "praxec", "args": ["serve"] }
    }
  },
  "agent": {
    "default_profile": "write",
    "profiles": {
      "praxec": {
        "name": "Praxec",
        "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": {
          "praxec": {
            "tools": {
              "praxec.query": true,
              "praxec.command": true
            }
          }
        }
      }
    }
  }
}

That’s two things:

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

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

Cursor

Paste this into .cursor/mcp.json:

{
  "mcpServers": {
    "praxec": {
      "command": "praxec",
      "args": ["serve"],
      "env": {
        "PRAXEC_CONFIG": "${workspaceFolder}/praxec.yaml"
      }
    }
  }
}

Restart Cursor. The 2 praxec 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 praxec’s. If you want strict “only praxec” governance in Cursor, enforce it in gateway.yaml — declare all the side-effecting connections (shell, GitHub, etc.) behind praxec’s connections: proxy with appropriate guards. The editor side stays permissive; the gateway side stays strict.

Claude Desktop

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

The snippet shape:

{
  "mcpServers": {
    "praxec": {
      "command": "praxec",
      "args": ["serve"],
      "env": {
        "PRAXEC_CONFIG": "/absolute/path/to/your/praxec.yaml"
      }
    }
  }
}

Restart Claude Desktop. Praxec’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 "praxec": { ... } key alongside the existing ones. Don’t overwrite the whole mcpServers block; you’d lose your other servers.

Claude Code

Two equivalent ways.

Via .mcp.json

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

{
  "mcpServers": {
    "praxec": {
      "command": "praxec",
      "args": ["serve"]
    }
  }
}

Via the CLI

claude mcp add praxec -- praxec serve

That registers praxec 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:

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)

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 praxec 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.

Workflow-driven editors

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 (praxec TUI, in the praxec-tui crate). Workflows you author here run under both.

What’s next