MCP server
keryx mcp exposes Keryx to any MCP client over stdio. The tool list is
the product API — the same nouns the REST surface and the CLI use.
Tools
| Tool | Does |
|---|---|
investigate(alert | query, context?) | Start an investigation; returns an id immediately |
get_investigation(id) | Status, finding, conviction |
list_investigations(filter) | Reverse-chronological list |
get_trace(id) | The full evidence-cited trace |
resolve(id, resolution) | Close an investigation |
Read-only is enforced in the call handler
Not at tools/list. This distinction is the entire lesson of
CVE-2026-46519, which hit a widely used Kubernetes MCP server whose
read-only flag was enforced when listing tools but not when calling them —
so anything that skipped the listing step got a write-capable server.
Keryx enforces the read-only guarantee where the call actually happens, and a denylist test asserts it across every mounted server's write-capable tools. The MCP flag is defense in depth; the enforcement boundary is the read-only RBAC ServiceAccount and the read-only GitHub token.
Telemetry is fenced, including here
An MCP client is another consumer of the same attacker-influenced telemetry.
Tool output crosses into a model's context inside nonce-fenced blocks, and
keryx mcp is a data passthrough by design — it does not re-render prose,
which is why the prose floor that suppresses unsupported model claims is
applied at emit time rather than only at render time.