v0.4.0

v0.4.0 — list_releases, upgrade briefings, and privacy as a ladder

A minor-version worth of change, field-tested against a real in-cluster agent (kagent) whose failures shaped every item.

New tool

• list_releases(project, limit) — the newest N reviewed releases of one project as light summaries (fact counts by severity, max advisory-group severity), newest first. THE tool for "recent releases of X" — list_facts is an oldest-first sync feed and must not be used for recency questions.

Upstream API additions (live at ratatosk.io/v1)

• GET /v1/upgrade/{project}?from=&to= — everything you take on by upgrading: facts from every release in between, the same advisory folded across release branches (envoy 1.36.8→latest: 75 facts → 40 distinct issues). Tag spelling never matters.
• version_rank on facts and release summaries — sortable integer components so REST callers can range-compare locally without sending their versions anywhere.
• Version tags accepted with or without the leading v; wrong tags 404 with the project's recent reviewed tags to retry with; project slugs matched case-insensitively.

Privacy, stated precisely

Three rungs, most private first:

1. check_stack — versions compared locally; only slugs reach the server. Now guaranteed in writing: check_stack never calls the server-side /v1/upgrade endpoint.
2. version_rank — pull facts, compare locally, send nothing.
3. /v1/upgrade — convenient; the versions you send reach the server. They are never written to access logs (query strings stripped, IPs masked v4 /24 / v6 /48 — see ratatosk.io/privacy), and the endpoint discloses this itself.

Improvements

• Error bodies pass through up to 400 chars so self-correcting 404s (with retry-able tag lists) arrive intact.
• Tool descriptions state list_facts ordering explicitly (oldest analyzed first; page with next_since).

No breaking changes.

v0.3.6

Severity judgments now follow the advisory group, not the single release

check_stack now prefers the server's group_severity — the maximum severity across every release branch sharing an advisory — when filtering, folding and building the briefing. The same fix often lands on several branches with differently-worded notes; one branch's milder wording no longer hides an issue below your severity_min.

• Facts citing only CVE ids (no GHSA or vendor advisory) now carry a cve:… group key, so branch-parallel fixes collapse into one briefing entry with one consistent severity.
• Tool and field descriptions explain the group keys and when to prefer group_severity.
• On older servers without group_severity, check_stack keeps the previous local fold.

Full Changelog: v0.3.5...v0.3.6

v0.3.5

The server now tells you its real version

Every release before this one identified itself as ratatosk-mcp/0.2, no matter the actual version. The version is now stamped at build time, so the MCP handshake and the User-Agent header both report the real one.

Also in this release:

• kagent integration: kagent.enabled Helm toggle or plain manifests; the example agent is now named ratatosk-agent and discovers running versions itself through kagent's read-only cluster tools (kagent.agent.k8sTools, on by default)
• Runs clean under Pod Security Standards restricted (seccompProfile added)
• Security policy (private vulnerability reporting) and contributing guide

Full Changelog: v0.3.4...v0.3.5

v0.3.4

Registry namespace fixed; now listed officially

No behavior changes. The registry namespace is case-sensitive to the GitHub username (io.github.garlicKim21, not io.github.garlickim21); this release corrects the server name and image label to match. With it, the server is published in the official MCP registry as io.github.garlicKim21/ratatosk-mcp, and every future release publishes there automatically.

Full Changelog: v0.3.3...v0.3.4

v0.3.3

Groundwork for the official MCP registry

No behavior changes. This release adds the metadata the official MCP registry requires for OCI ownership verification: the io.modelcontextprotocol.server.name image label, a server.json, and a workflow that publishes each release to the registry automatically.

Full Changelog: v0.3.2...v0.3.3

v0.3.2

Agents can now look up project slugs instead of guessing

A new list_projects tool returns the tracked-project roster — slug, name, tier, category, and analyzed release count — backed by the new public GET /v1/projects endpoint. Until now an agent that guessed a slug wrong only found out via tracked: false; now it can resolve the slug first. The tool description tells agents to do exactly that.

detail: "full" responses are also capped:

• At most 50 facts per component, with the cut counted in relevant_facts_omitted — never silent. A long upgrade path could previously return tens of thousands of tokens in one response.
• Narrow with severity_min or target_version when you need the full picture in slices.

Full Changelog: v0.3.1...v0.3.2

v0.3.1

An untracked project no longer looks safe

check_stack used to answer with zero facts whether a project was tracked and quiet, or simply unknown to ratatosk — and an agent reading "no facts" as "no risk" would be wrong in the second case. Components with zero facts now carry an explicit tracked: true|false: tracked-and-quiet says the releases were read and routine, untracked says plainly that zero facts means no coverage, not safety.

Brief mode also got tighter for fact-heavy releases:

• Facts that share one quoted sentence (one extraction sentence covering several CVEs) are merged into a single entry — ids listed together, strongest severity shown, diverging applies_if conditions collected into applies_if_any. Previously the same sentence could repeat once per CVE.
• Summary counts are unchanged: they still count distinct issues.

Full Changelog: v0.3.0...v0.3.1

v0.3.0

get_release without a version

get_release now treats version as optional: omit it and the server returns the project's latest reviewed release. Agents usually know the project but not its newest tag, and the facts endpoints cannot surface routine zero-fact releases — this was the missing discovery path.

• Pairs with the new /v1/releases/{project} form on ratatosk.io (the version segment is now optional there too).
• Calls with an explicit version are unchanged.
• Helm chart appVersion now tracks releases — the chart previously defaulted to the 0.1.0 image tag.

v0.2.2

The server introduces itself

Connecting clients now receive MCP instructions in the initialize handshake — the ground rules an agent should know before calling tools:

• Facts are extracted by AI from official release notes; verify critical decisions against the source URL in get_release (terms: https://ratatosk.io/terms).
• The upstream API is rate-limited to 60 requests/minute per IP — for stack-wide questions, one check_stack call beats polling list_facts per project.

Tool behavior is unchanged.

v0.2.1

One advisory, one entry, one severity

Each release note is analyzed independently, so the same advisory used to appear once per branch — sometimes with different severity grades (observed live: envoy CVE-2026-47692 rated high on v1.36.9 but critical on v1.37.5, listed twice in one briefing).

• check_stack briefings now fold on the advisory group (falling back to the per-note issue key when no advisory is attached).
• A folded entry shows the strongest judgment across its branches, and is mandatory if any branch says so.
• Summary counts follow the folded entries: an envoy v1.36.8 briefing drops from 38 to 20 distinct issues, and the critical count reads 3 — the real number of distinct critical advisories.

Stored facts are untouched; each still carries its verbatim quote and source URL.