Skip to main content
Endpoint: /builder/mcp
Permission: Build (odin:build) — consent label Build in your workspace Builder does not chat with Autopilot on your behalf. It hands the MCP client the same build tools Autopilot has and lets that client’s model plan and call them — for example creating an agent or editing a workflow. Tool lists are not hardcoded. The server asks EKB which tools the live Autopilot / composer template currently grants, so changes to Autopilot show up over MCP without a separate redeploy. Tool names match EKB toolkit names (for example create_agent_from_config, add_and_verify_node_to_workflow).

​
Prerequisites

  • Consent to Build in your workspace for this client
  • Project membership that allows creating/editing the resources you intend to change
  • Willingness to treat tool calls as production writes in a live workspace

​
What you can do

  • Create and modify agents, workflows, smart tables, interfaces, and knowledge bases
  • Use the same toolkit operations Autopilot uses inside EKB (minus UI-only tools)
  • Read per-toolkit guides as MCP resources (odin://guides/<toolkit>) or via the build-guide tool
  • Call get_odin_build_guide for the full operating playbook (and optional per-toolkit guides)

​
Build guide and instructions

Many MCP clients truncate the server instructions field (some as low as ~2048 characters). EKB therefore:
  1. Sends a short briefing in instructions that tells the model to call the guide tool first
  2. Serves the full Autopilot playbook through get_odin_build_guide
  3. Exposes toolkit guides as resources under odin://guides/ and as optional toolkit arguments on the guide tool
Call get_odin_build_guide() before building anything in a session. Pass a toolkit name (for example workflow_manager) when you need that toolkit’s detailed rules.

​
How it differs from Autopilot in the product

UI-only Autopilot tools (such as in-chat widgets like ask-user) are excluded — MCP clients cannot render them.

​
Project context

Builder does not pin to a project via x-project-id. The model should:
  1. Discover projects (for example via a list-projects style tool, or Runtime’s list_odin_projects)
  2. Pass the target project id on every create or update call as target_project_id or project_id (follow each tool’s schema)
  3. Never invent ids — look resources up and reuse ids EKB returns
  1. Connect only the Builder URL on machines that should change configuration
  2. Call get_odin_build_guide() (and the relevant toolkit guide) before first writes
  3. Plan work (todo list), then create or modify resources with an explicit project id
  4. Verify what you built by testing it — do not report success on create alone

​
When to use Builder

  • Scaffolding agents or workflows from Cursor / Claude Code
  • Bulk or iterative configuration changes driven by an external coding agent
  • Keeping build access off machines that should only use EKB — connect Runtime alone instead

​
Troubleshooting