Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.

io.github.garlicKim21/ratatosk-mcp

OCI · GHCR.IO/GARLICKIM21/RATATOSK-MCP:0.6.2 · SCANNED AUG 3

CNCF release intelligence: typed facts from release notes; check_stack compares versions locally.

34 Trust /100
Trust breakdown (6 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score →

Supply Chain Security0
  • Malware scan not yet available for this package.Unverified
  • CVE data not yet available for this package.Unverified
  • Install-script risk not yet assessed.Unverified
  • Dependency-health data not yet available.Unverified
Provenance & Transparency32
Schema Quality & AI Usability61
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 1550 tokens (~258/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
  • Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass

Unverified: 2 categories

Categories scored 0 because we could not verify them: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Install

Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.

oci · ghcr.io/garlickim21/ratatosk-mcp:0.6.2

# add to Claude Code
claude mcp add garlickim21-ratatosk-mcp -- docker run --rm -i ghcr.io/garlickim21/ratatosk-mcp:0.6.2
# add to Codex CLI
codex mcp add garlickim21-ratatosk-mcp -- docker run --rm -i ghcr.io/garlickim21/ratatosk-mcp:0.6.2
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "garlickim21-ratatosk-mcp": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/garlickim21/ratatosk-mcp:0.6.2"
      ],
      "enabled": true
    }
  }
}
# ~/.hermes/config.yaml
mcp_servers:
  garlickim21-ratatosk-mcp:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/garlickim21/ratatosk-mcp:0.6.2"]
// mcp.json
{
  "mcpServers": {
    "garlickim21-ratatosk-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/garlickim21/ratatosk-mcp:0.6.2"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 1 Aug 26 +28
    • Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window). security
    • MCP protocol: unverified → pass functional
    • Tool coverage: unverified → 100 functional
    • First check of Tool coverage: 100 functional
    • First check of Schema quality: fail functional
    • First check of Schema quality: excellent functional
    • First check of Schema quality: fail functional
  • 31 Jul 26 6

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 3 Aug 2026 · Analysed oci/ghcr.io/garlickim21/ratatosk-mcp:0.6.2

Provenance none

Ecosystem: oci · Outcome: none

Reason: no_attestation

MCP tools — 6 exposed · ~1,465 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.

Tool Tokens
check_stack ~464

Check the user's running component versions against known facts. Versions are compared INSIDE THIS SERVER PROCESS — only project slugs are sent upstream, and this tool never calls the server-side /v1/upgrade endpoint. Run the server yourself and running versions never leave your infrastructure; on the hosted endpoint they transit server memory only and are not logged. Returns, per component, the facts from releases NEWER than the running version (the upgrade path). Default is a briefing: summary counts, then critical/high facts split by whether the caller still has to check something — action_required applies to everyone, check_config applies only if its applies_if holds against the running configuration (resolve it before recommending; an unmet condition is not a reason to upgrade, it is a precondition for later — fixed_in is the minimum version to be on before enabling that feature). One line each for the rest, and the same advisory fixed on several release branches collapsed into one entry (shown at the advisory's group-maximum severity). Pass version_source per component (where you read the version — e.g. a daemonset image tag, or that the user stated it): it is echoed back as an audit trail. This server cannot see your environment, so it cannot verify a version or its source; a running version older than every release on record is flagged in note, which is the only cross-check available here. Use detail:"full" for every fact verbatim (capped at 50 per component with relevant_facts_omitted — narrow with severity_min or target_version), target_version to limit to one upgrade hop, severity_min to filter. Components with zero facts carry tracked:true|false — tracked:false means the project is NOT covered by ratatosk, so the absence of facts is no-coverage, not safety. In brief mode, facts sharing one quoted sentence are merged with their ids listed together. Drill down with get_release or facts_by_entity.

NameTypeReqDescription
componentsnull|arrayyesthe running stack to check
detailstringbrief (default): summary + critical/high facts + one-liners for the rest; full: every fact verbatim
severity_minstringonly facts at or above this severity: info|low|medium|high|critical

No output schema declared.

No examples provided.

facts_by_entity ~139

Reverse index: every fact touching one exact identifier — a CVE id, CRD, feature gate, flag, metric, config field, or dependency. Case-insensitive. Call this when you have a specific identifier (e.g. from a manifest or advisory) and want to know what changed around it.

NameTypeReqDescription
kindstringoptional: api|crd|feature_gate|flag|metric|config_field|extension|dependency|cve|advisory|subsystem
namestringyesexact identifier to look up: CVE id, CRD, feature gate, flag, metric, config field, dependency

No output schema declared.

No examples provided.

get_release ~202

One reviewed release: envelope (coverage, assessment, source URL) plus all its facts. facts=[] with coverage=full_reviewed means the release was read and is routine — auditable silence. Omit version for the latest reviewed release of the project. version is accepted with or without the leading 'v' (projects disagree on the spelling); a wrong tag returns an error listing the project's recent reviewed tags — retry with one of those. Set include_raw for the original release note body (raw_notes); when the review is not the full story (coverage insufficient, or zero facts) raw_notes is included automatically.

NameTypeReqDescription
include_rawbooleanalso return the original release note body as raw_notes — judge from the source instead of the extracted facts
projectstringyesproject slug, e.g. envoy
versionstringrelease tag exactly as published, e.g. v1.38.3; omit for the latest reviewed release

No output schema declared.

No examples provided.

list_facts ~320

Incremental SYNC feed of release facts (typed, entity-level changes: security fixes, removals, deprecations, renames, defaults) for CNCF/cloud-native projects. Ordered by fact_id ascending — OLDEST analyzed first, so a single page is NOT the newest data; page through with since=<returned next_since> until next_since comes back null. Built for keeping a local copy up to date. For 'what is the latest release of X' or 'recent releases of X', use get_release (omit version for the newest) instead. Optionally filter by project/type/severity. Facts citing an upstream security advisory carry advisory_group_key (the official notice id, e.g. GHSA-… on GitHub; facts citing only CVE ids get a cve:… key) and group_severity — the maximum severity across all releases sharing that key — the group-maximum reading, with per-release severity as the per-release evidence.

NameTypeReqDescription
limitintegerpage size, default 50, max 200
projectstringproject slug filter, e.g. envoy, istio, cilium
severitystringinfo|low|medium|high|critical
sinceintegercursor: return facts with fact_id greater than this
typestringfact_type filter: security_fix|dependency_bump|capability_removed|capability_deprecated|api_version_changed|identifier_renamed|validation_tightened|default_changed|behavior_changed

No output schema declared.

No examples provided.

list_projects ~194

Every project ratatosk tracks: slug (the canonical id all other tools take), name, tier (graduated|incubating), category, analyzed_releases; image_aliases where a project runs under other names in clusters (an image or workload matching an alias belongs to that project at the version its tag says), and cluster_core:true on the cluster substrate (control plane, datastore, DNS, runtime, CNI/dataplane) — every cluster_core project present in a cluster belongs in its check_stack call. Some cluster_core entries carry a visibility hint (how the component is observed and where it can legitimately be unreadable — e.g. etcd may live outside the k8s API): an unreadable one is reported as unchecked, never guessed. Small response, no arguments — call this FIRST when you are unsure of a slug instead of guessing (a wrong slug shows up as tracked:false in check_stack).

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

list_releases ~146

The newest N reviewed releases of one project, as light summaries (version, date, coverage, fact counts by severity, max advisory-group severity). THE tool for 'recent releases of X' / 'what changed in X lately' — newest first, unlike the list_facts sync feed which returns oldest-analyzed first. facts_total=0 with coverage=full_reviewed means the release was read and is routine (auditable silence). Drill into a row with get_release(project, version) for the full facts.

NameTypeReqDescription
limitintegerhow many recent releases, default 5, max 20
projectstringyesproject slug, e.g. istio

No output schema declared.

No examples provided.