Skip to main content
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. 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

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:
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