Skip to main content
Most MCP docs describe connecting external tools into an EKB agent. This section is the other direction: expose EKB itself as MCP servers so any MCP-compatible client — Claude, Cursor, ChatGPT, or a custom agent — can build and use your workspace.

​
Prerequisites

  • An EKB account with access to at least one project
  • An MCP client that supports HTTP MCP URLs and OAuth (or custom headers for API keys)
  • For production-style hosts, network access to your environment’s MCP hostname (for example https://mcp.getodin.ai)
  • For headless CI, a user-level API key and secret

​
Two servers, two kinds of access

EKB publishes two MCP endpoints. They are separate on purpose: asking a support agent a question is a smaller grant than letting a client create or rewrite agents, so they do not share a consent screen or a token. A token issued for Runtime cannot be reused on Builder, and vice versa. “Use” access cannot escalate into “build” access. On the consent screen, EKB names the MCP client and the permission it is requesting. Nothing is granted until you approve or deny. Declining returns access_denied to the client instead of leaving it hanging.

​
When to use which

​
How access is limited

Three layers always apply:
  1. Audience — the token is valid only for the server you authorized (Builder or Runtime)
  2. Scope — odin:build vs odin:use
  3. Your EKB permissions — the client acts as you; project membership, Access Tags, and publish state still apply
The MCP service holds no credentials of its own. Every call forwards your OAuth token or API key.

​
Next steps

  1. Connect a client — add Builder and/or Runtime URLs
  2. Authentication — OAuth consent, scopes, and API keys for CI
  3. Builder or Runtime — what each server exposes