API and MCP

The open sessions list on the My account page has a “Create token” button. You give the token a name, a lifetime (30, 90, 180 or 365 days) and a scope: Read (the default) or Propose plans (see Plan proposals). Creation is accepted only from a browser session with a sign-in in the last 10 minutes; if your sign-in is older, the interface asks you to sign in again. This means users who sign in with SSO can create tokens too.

The value is shown only at creation. YEKE does not keep it in plain form and cannot show it again. The token sits in the same list as your open sessions (name, read or plan label, expiry, last use); “End” there revokes it. Each user can have up to 20 active tokens (both scopes counted together), with unique names.

Send the token as a Bearer token in the Authorization header of every request:

curl https://yeke.example.com/api/clusters -H "Authorization: Bearer $YEKE_READ_TOKEN"

The owner can lower the token lifetime ceiling in System settings → Sessions & access → "API token lifetime"; lowering it applies to existing tokens right away. 0 turns API tokens off entirely.

Read proxy

A GET /api/clusters/<id>/k8s/<apiserver path> request carries the Kubernetes API path as is. The read runs under your Kubernetes identity on that cluster; the token shows nothing your Kubernetes RBAC does not. The response body is Kubernetes' own response; YEKE does not change it.

curl -i https://yeke.example.com/api/clusters/c-1/k8s/apis/apps/v1/namespaces/payments/deployments \
  -H "Authorization: Bearer $YEKE_READ_TOKEN"

A successful read with a Bearer token carries a link to the object's or list's YEKE screen in the Link header (rel="alternate"). A dashboard or an ITSM ticket can use that link directly.

Metrics

YEKE's own metric store is read through GET endpoints: status, overview, nodes, workloads, pods and pvcs under /api/clusters/<id>/metrics/, plus /node-metrics and /pod-metrics for a live probe. What you get is bound to your Kubernetes RBAC. History depth is the same as on the Monitoring page.

• Read token: only GET and HEAD. Write requests, the Shell, port-forward and live subscription connections, and admin endpoints get 403. The token cannot copy or revoke itself.
• Plan token: reads plus one write, building a plan. On top of everything a read token can do, it can only build plans with POST /api/clusters/<id>/operations. Applying, approving, refreshing, cancelling and reverting plans; the interface's own plan endpoints (access grants, permission groups, Secret writes and restores); starting scans; creating tokens; the Shell and admin endpoints all get 403.
• Secret values at least masked. Whatever the installation's Secret visibility setting, a Secret value read with the token never comes back in plain form. A stricter setting wins.
• Rate limit. Each token has a per-minute request budget (600 by default). A request over it gets 429 and a Retry-After header. A plan token also has a limit of 10 proposals a minute.
• Revocation. “End”, changing or resetting your own password, and disabling the account revoke your tokens. A revoked or expired token gets 401. Removing the second factor does not drop tokens.
• No idle timeout. The token is valid until the end of the lifetime you chose.

YEKE's MCP server (/api/mcp) opens the YEKE chat's read tools to your own agent: objects, events, logs, metrics, operations and the audit record. The tools are the same as in the chat and go through the same masking. Reads run under your Kubernetes identity, every read lands in the audit trail, and each one counts against the token's rate limit.

• The owner turns on the switch. System settings → Sessions & access → “MCP server”; core does not need a restart. While it is off, the endpoint returns 403 MCP_DISABLED. The state is also shown on the AI providers screen in administration. If the deployment sets YEKE_MCP_ENABLED=1, the field shows as locked in the UI.
• An administrator picks the clusters. Only clusters that allow AI data egress are open to MCP (cluster screen → chat panel → egress and provider setting). Clusters with egress off or limited to a local model cannot be read over MCP, because YEKE cannot tell which model the data would go to.
• The user creates a token. MCP accepts only a scoped token: a read or a plan token. A browser session and the full token from yeke login are rejected.

MCP cannot write directly: not to the cluster, not to YEKE's own settings (alert rules, Hooks, permission groups, users, policies). An agent connected with a plan token can only propose a plan; you approve it in YEKE (see Plan proposals). The agent tells you which YEKE screen a management task belongs on; you do it in the interface.

Tools, an example session and troubleshooting: MCP guide.

The shortest path is the account page. When MCP is on, a “Use with MCP” section opens right under a new token, with Claude Code, Claude Desktop, Codex and Cursor tabs. Each tab gives a one-sentence instruction and a single snippet to copy that contains the token; the token is written in plain text to the client's configuration in your home directory. Claude Desktop connects to YEKE through the mcp-remote bridge and needs Node.js. To keep the token in an environment variable instead, use the forms below.

Claude Code

With a .mcp.json file at the project root; the token is read from the environment variable:

{ "mcpServers": { "yeke": { "type": "http", "url": "https://yeke.example.com/api/mcp",
  "headers": { "Authorization": "Bearer ${YEKE_MCP_TOKEN}" } } } }

Or with a command:

claude mcp add --scope project --transport http yeke https://yeke.example.com/api/mcp \
  --header 'Authorization: Bearer ${YEKE_MCP_TOKEN}'

Keep the header in single quotes: the shell does not expand the variable, Claude Code writes the string as is into .mcp.json, and the variable is expanded at run time. With double quotes, the token is written in plain text into the Claude Code configuration.

Codex CLI

In ~/.codex/config.toml. Codex has no command flag for Bearer; the token is read from the environment variable through this key. We recommend keeping tool approval on:

[mcp_servers.yeke]
url = "https://yeke.example.com/api/mcp"
bearer_token_env_var = "YEKE_MCP_TOKEN"
default_tools_approval_mode = "prompt"

Internal CA

If YEKE uses a certificate signed by your organization's own CA, use the yeke mcp relay (YEKE CLI 0.5.0 and later). The relay trusts the CA saved with yeke login --ca-file (see Internal CA) and reads the token only from the YEKE_MCP_TOKEN environment variable; it never uses the CLI's own full token for MCP.

claude mcp add --env YEKE_MCP_TOKEN=<token> --transport stdio yeke -- yeke mcp

[mcp_servers.yeke]
command = "yeke"
args = ["mcp"]
env_vars = ["YEKE_MCP_TOKEN"]

With an expired or revoked token, MCP returns 401; create a new one on the My account page.

A plan token is created on the My account page by choosing the Propose plans scope when you create a token; creation rules, lifetime and revocation are the same as for a read token. With it, a script, an ITSM flow or your own AI agent proposes a change: YEKE runs the plan through the same chain as plans from the interface and the chat (validation, dry-run, policies) and builds an approval card. The token cannot apply the plan. The plan is built in your name; you open the card in your own session and review, approve or reject it.

Over REST

The body is the raw HTTP intent the interface uses. The note field appears on the card as “Client's note”; the intent field is not accepted on this path (that field is the sentence you write in YEKE).

curl -X POST https://yeke.example.com/api/clusters/c-1/operations \
  -H "Authorization: Bearer $YEKE_PLAN_TOKEN" -H 'content-type: application/json' \
  -d '{"request":{"method":"PATCH","path":"/apis/apps/v1/namespaces/payments/deployments/web",
       "contentType":"application/merge-patch+json","body":{"spec":{"replicas":3}}},
       "note":"night scaling"}'

The response is the plan itself and carries the approval card's relative link in the href field (/clusters/<id>/operations?op=<id>). A …/apply call with the same token gets 403.

Over MCP

If the token has the plan scope, the chat's proposal tool propose_operation also appears in the agent's tool list; it is not shown to a read token. The tool does not apply the change; it builds an approval card and returns the card's link. If YEKE's external address (System settings → Address & certificate) is not set, the link comes back as a relative path. The tool returns no values: it returns the plan's state, the approval level, the verbs, the policy codes and the paths of the changed fields. The agent's summary appears on the card as “Model's summary”. If the client drops the connection, the plan is still built.

Approval card

• It says where the plan came from. The card names the token that proposed the plan and whether it came over the API or MCP. The token name is frozen on the card; it still shows if the token is later removed.
• It keeps the note apart. The client's or model's note sits on its own labelled line.
• Approval is yours. Refreshing and applying the plan belong to the token's owner and are closed to the token itself; you approve the card in your own YEKE session.

Replacement and rate limit

• A new proposal replaces the old one. When the same token proposes a new, approvable plan for the same cluster, that token's pending card on that cluster is cancelled. REST and MCP proposals replace each other. A denied or blocked proposal does not cancel the older card. Use two separately named tokens for parallel changes.
• 10 proposals a minute. The limit is per token, and REST and MCP share the same budget. A request over it gets 429 and Retry-After. The read budget is counted separately.

Policy: ops.nl-strict

When the built-in ops.nl-strict template is turned on, every write proposed with a plan token (REST or MCP) asks for elevated approval, along with writes from chat. Your own rules can read the origin through op.origin; see Policies.

https://yeke.example.com/clusters/<id>?chat=<url-encoded text>

• It never sends by itself. The text is written into the chat box; sending is your gesture.
• It does not overwrite your text. If you have already typed something, you choose whether to replace it with the link's text.
• It says where the text came from. A label above the box says the text came from a link. The parameter is removed from the address once read; reloading the page does not write it again.
• Anyone can build such a link. Who wrote the text cannot be known; read it before sending. Every write from the chat still goes through the approval card.

For object and operation links (/clusters/<id>/r/…, /clusters/<id>/operations?op=…), see the 0.69.4 release note.

• MCP is not a data loss prevention (DLP) boundary. MCP output goes through the same privacy gate as the chat, and Secret values are masked. But the same token can fetch the raw object from the read proxy, and log lines cannot be masked at all. The gate does not stop users from carrying data they can already see on screen to their own model; it keeps the default path safe and shows every read in the trail.
• Data goes to the model you choose. A cluster that allows AI data egress does not distinguish between your organization's contracted provider and a personal subscription. Turning the switch on applies to every cluster that allows egress.
• The agent's other tools. The agent runs on your machine alongside shell, file and web tools. An instruction embedded in a pod log can talk it into sending out the data it has read; that is the client's trust boundary. Keep tool approval on in the client.
• The local full token. The full token from yeke login lives in the CLI configuration on your machine, and the same agent can read it from the file system. MCP neither creates nor reduces this risk.
• An agent driving the browser. If your agent also drives your browser, it can press “Approve” in the YEKE interface itself; YEKE cannot tell it apart from a person. A user who hands their browser to an agent hands over the approval gesture too.
• Management tasks cannot be done over MCP. The agent only tells you which screen they belong on.
• A plan lives 30 minutes. A proposed plan that is not approved within 30 minutes expires; this cannot be changed. A link opened late shows the expired card; the way forward is to propose again.
• Simultaneous proposals. Two proposals arriving at the same moment from the same token can leave two pending cards; replacement works for proposals made one after the other.
• The proposal limit is per replica. The 10-a-minute limit is counted separately in each core process; in an installation with several replicas, the total limit is multiplied by the replica count.
• A user removed in the identity provider. The token of a user removed in LDAP or OIDC stays valid until it expires or the user is disabled in YEKE.