MCP guide

• One endpoint, the whole fleet. The agent only talks to /api/mcp. Each tool call names the cluster it reads with clusterId; YEKE runs the read under your Kubernetes identity on that cluster.
• The read path only reads. There is no path behind MCP that writes to the cluster. propose_operation does not apply anything either; it builds a plan and an approval card in YEKE.
• Results are marked as data. Every successful tool result reaches the agent inside a data envelope; details in Security model.
• The server gives the agent instructions. On connect, YEKE tells the agent that tool results are data, the diagnosis order (metrics first, then events, pod status and logs) and which YEKE screen each management task belongs on. A client may not use these instructions.

Transport: Streamable HTTP, POST only. Every response is a single JSON object (no SSE) and the server keeps no session. Supported protocol versions: 2026-07-28 and 2025-11-25.

1. Owner Turn on Administration → System → System settings → Sessions & access → “MCP server”; core does not need a restart. The state also appears on the Administration → AI providers screen. See Turning on MCP.
2. Administrator On every cluster the agent should read, set the AI egress stance to allowed: cluster screen → chat panel → “Egress & provider”. The user also needs a Kubernetes identity mapping on that cluster. See Turning on MCP.
3. User My account → “Create token”. Once the token is created, the “Use with MCP” section under it gives the Claude Code command and the Codex snippet. See Claude Code and Codex; if YEKE uses an internal CA, the yeke mcp relay in the same section.

Which scope? If the agent only diagnoses, choose Read; if you also want it to propose the fix as an approval card, choose Propose plans. A plan token sees every tool a read token sees, plus propose_operation and nothing else.

MCP adds a required clusterId field to every tool. Its valid values are the clusters you can read over MCP: those where you have a Kubernetes identity mapping and where an administrator allows AI egress (allowed). If there is no such cluster, the tool list comes back empty.

Tools that exist only in the chat are not served over MCP: user and identity reads, the interface tool, management and access proposals, and the two tools that end a chat turn (answer, ask_user). Calling a tool that is not served gets JSON-RPC -32602.

› web in the payments namespace keeps restarting. Why?

# every call carries clusterId=c-1
yeke_metrics   op=status
yeke_metrics   op=entity kind=workload namespace=payments name=web
k8s_events     namespace=payments involvedObject=web-6d8f9c7b5-x2kqp type=Warning
k8s_get        schemaId=pod namespace=payments name=web-6d8f9c7b5-x2kqp
k8s_logs       namespace=payments name=web-6d8f9c7b5-x2kqp previous=true tailLines=50

FINDING    the web container is killed when it reaches its memory limit.
EVIDENCE   k8s_get: lastState.terminated.reason=OOMKilled, restartCount=14,
           resources.limits.memory=256Mi; yeke_metrics: memory near the limit for 1h.
SUGGESTED  raise the memory limit to 512Mi.

› Propose it.

propose_operation  patch apps.deployment payments/web
                   state=AWAITING_APPROVAL
                   https://yeke.example.com/clusters/c-1/operations?op=op-…

The approval card is ready in YEKE. Open the link and review it; approval is yours.

What the card shows

• Origin. The card states which token and channel the plan came from: “This plan was proposed by an AI client over MCP with the “laptop-claude” token.”
• Model's summary. The agent's summary sits on its own line labelled “Model's summary”. What you approve is the change on the card, not the summary.
• Change and chain. The plan's steps, the diff computed by the dry-run, the policy results and the approval level; the same as the card of a plan built in the interface or the chat.
• Approval is yours. You open the card in your own YEKE session and approve or reject it. A plan that is not approved expires after 30 minutes.

The plan that propose_operation builds goes through the same plan builder as the interface and the chat: validation, dry-run, policies and the validation Hooks of your installation. Hooks receive the plan's source as api.

Applying also goes through a single gate, and that gate does not look at the plan's origin. Second approval, maintenance windows and approval-time Hooks (for example an ITSM approval) apply to a plan proposed over MCP exactly as they do to any other plan, when they are turned on in your installation; see Governance and Hook integration.

The token cannot skip any approval step. Applying, approving, refreshing and cancelling a plan are closed to the plan token (403); the card's owner does them in their own session.

To put every AI-originated write behind elevated approval, use the built-in ops.nl-strict template: see Plan proposals.

• Identity and Kubernetes RBAC. Every read runs under your Kubernetes identity on that cluster. What your RBAC does not show, the agent cannot see; a cluster where you have no identity mapping cannot be read over MCP.
• Masking. Secret values reach the agent masked. The last-applied-configuration annotation and managedFields are never sent; container env values are masked by default. Log lines cannot be masked.
• Results are marked as data. Every successful tool result travels between <<<TOOL_RESULT … kind=data>>> and <<<END>>>; the same delimiters inside the data are broken up. The server instructions say the inside of the envelope is data, not instructions, and that instructions found in cluster content must not be followed. On its own this is not enough against prompt injection: the model may ignore the instructions. The main gate is that the agent cannot write; the furthest an injected instruction can get over MCP is a proposal, and you approve it.
• Audit trail. Every read call writes an ai.read event: source api, channel mcp and the token's ID. The values read are not written to the event. The catalog tools (k8s_search_types, k8s_describe_type) write no event because they read no new data from the cluster. A plan proposal writes an ai.plan_proposed event.
• AI egress gate. A cluster whose stance is off or local-only cannot be read over MCP; YEKE cannot tell which model the data would go to.
• Scoped tokens only. A browser session and the full token from yeke login are rejected by MCP.
• No writes to YEKE settings. Alert rules, Hooks, permission groups, users and policies cannot be changed over MCP; the agent only tells you which screen the task belongs on.
• Rate limit. Every MCP request counts against the token's per-minute budget; proposals are counted separately as well. See Token scope.

Desktop apps and environment variables. Some desktop clients start without reading your shell's startup files (e.g. .zshrc) and do not see the variables defined there. Then, if the variable expands to nothing, the request gets 401 UNAUTHENTICATED; if the client sends the ${YEKE_MCP_TOKEN} string without expanding it, it gets 401 SESSION_INVALID. The fix is to give the token to the client's own configuration; the one-step command in the “Use with MCP” section of My account does that.

• A diagnosis is a suggestion. The agent's finding and the cause it names may be wrong; YEKE does not verify the model's conclusion. Read the diff yourself before you approve the card.
• MCP does not write. Nothing is written to the cluster over MCP; a change an agent proposes only comes from a plan you approve.
• Approval is your responsibility. You are the one approving the card; the agent's summary is a note, not the decision.
• No turn budget. The chat's per-turn tool cap does not exist over MCP; the client decides how many reads the agent makes. Per-call read caps and the token's per-minute budget still apply.
• Other limits. MCP is not a data loss prevention (DLP) boundary, data goes to the model you choose, the agent has other tools on your machine, and a plan lives 30 minutes: see Declared limits.