मुख्य सामग्री पर जाएं

Authentication

On first connection, the MCP client:

  1. Hits the Builder or Runtime URL
  2. Receives an authorization challenge
  3. Opens a browser consent screen for your EKB account (/oauth/consent)
  4. Completes an authorization code flow with PKCE
  5. Calls EKB with a token that represents you

You approve either build or use access depending on which endpoint you connected. Builder and Runtime do not share tokens.

ScopeLabel on screen
odin:buildBuild in your workspace
odin:useUse your agents and tools

The screen names the requesting MCP client and lists the permission. Approve or deny explicitly — nothing is granted by default. Denying redirects back to the client with error=access_denied so the client does not hang.

Pending consent requests expire. If the page says the request expired or was already used, start again from the MCP client.

Why two grants​

GrantScopeAudienceTypical use
Builderodin:build/builder/mcpCreate/change agents, workflows, tables, interfaces, KBs
Runtimeodin:use/runtime/mcpAsk agents, run published tools, search KB, query tables

A Runtime token fails if pointed at Builder (and the reverse). “Use my support agent” cannot escalate into “rewrite my agents.”

What the token can do​

Three layers apply:

  1. Audience — token is valid only for the server you authorized
  2. Scope — build vs use
  3. Backend allowlist — only an explicit set of EKB APIs is reachable over MCP

The MCP service holds no credentials of its own. Every call forwards your token (or API key). EKB still enforces normal project membership, permissions, publish state, and document Access Tags.

API keys (headless)​

CI and automation cannot complete a browser consent flow. Pass:

X-API-KEY: ...
X-API-SECRET: ...
Key typeBest for
User-levellist_odin_projects, multi-project Runtime, CI that must see several projects
Project-scopedAutomation locked to a single project

Example config: Connect a client.

Treat API secrets in MCP client config like any other credential — do not commit them to shared repos.

Security tips​

  • Connect Builder only on clients that should change configuration
  • Prefer Runtime alone for day-to-day assistants
  • Use HTTPS MCP URLs in production
  • Rotate API keys used for headless access
  • Revoke or reconnect if a laptop / client should no longer have build access
  • Remember: Access Tags and project roles still apply to Runtime search and agent answers

Troubleshooting​

SymptomWhat to check
Consent expiredRestart from the client; requests are short-lived
Token works on Runtime but not BuilderExpected — separate grants; connect and approve Builder separately
Headless calls fail across projectsUse a user-level API key
Client hangs after denyClient should handle access_denied; retry connection if needed