Kubernetes MCP Evaluation
| Repository metadata | Value |
|---|---|
| Hosting | Forgejo |
| Release Tag | unknown |
| Last update | 2026-10-05 on main |
| Owner | DevFW-CICD |
| Repository | Open repository |
The 30-second mental model
One question: can an agent, given only a generic Kubernetes tool, discover and correctly drive EdgeConnect CRDs — well enough that a bespoke EdgeXR MCP server is unnecessary?
Everything else is machinery to answer that fairly. Three different things could explain a failure, so each gets its own knob:
| Knob | Values | Isolates | Today |
|---|---|---|---|
| Arm | oracle / unhinted / hinted / skilled | Whose fault a failure is — the task set, the agent cold, the agent un-helped, or missing platform knowledge | all four |
| Tier | 1 / 2 / 3 | How real the cluster is — bare CRDs / fake controllers / kcp | Tier 1 |
| Archetype | generic vs per-resource | The shape of the server — why there are ~4 verbs, not one tool per CRD | settled, not a live knob |
And the output that matters is not the go/no-go — that is ~90% predictable. It is the
CRD-authoring feedback the failures generate (confusable kinds, thin descriptions,
unguessable fields), which lands while the CRDs can still change.
Why: docs/background.md.