Skip to main content
Glama
garlicKim21

Ratatosk

by garlicKim21
OverviewSchemaRelated ServersScoreDiscussions
Go
Remote

check_stack

Read-only

Compare running component versions against known release changes to identify security fixes, breaking changes, and required upgrade actions per component.

Instructions

Check the user's running component versions against known changes. 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 changes from releases NEWER than the running version (the upgrade path). Default is a briefing: summary (new_changes, distinct_matters, by_severity, by_family, by_bucket), then the items split by what the caller must do — 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 — the entry's version is the minimum to be on before enabling that feature). The split comes from the server's bucket field, the SAME rule the website and the weekly email use. Repeat appearances of one matter_key (the same issue fixed on several release branches) collapse into one entry, and same_matter_also_addressed_in names every other release on record that carried it. Branch-aware: a matter already fixed at or below the running version ON THE RUNNING BRANCH is excluded (the install has it), counted in note — so a backport visible on a newer branch is not reported as outstanding work. Line-aware: a repository can publish separate products or channels (containerd api/, Flatcar lts vs stable, openfeature flagd vs core) and there is NO version order between lines, so only the line your version belongs to is compared — pass the tag as published, prefix included ("flagd/v0.16.1", "lts-4081.3.9"), or the wrong line is compared. 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 change verbatim in relevant_changes (capped at 50 per component with relevant_changes_omitted — narrow with severity_min or target_version), target_version to limit to one upgrade hop, severity_min to filter. Components with zero changes carry tracked:true|false — tracked:false means the project is NOT covered by ratatosk, so the absence of changes is no-coverage, not safety. Drill down with get_release or changes_by_entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNobrief (default): summary + the items to act on, split by bucket; full: every change verbatim
componentsYesthe running stack to check
severity_minNoonly changes at or above this severity: info|low|medium|high|critical

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv0.9.0
    • addedInput schema / properties / components / anyOf
      Added value: +[
+  {
+    "description": "the running stack to check",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "project": {
+          "description": "project slug, e.g. envoy",
+          "type": "string"
+        },
+        "target_version": {
+          "description": "optional upgrade destination, strictly above the running version: only changes with running < version <= target are returned; a target at or below running would make that range empty and is ignored with a note",
+          "type": "string"
+        },
+        "version": {
+          "description": "the version currently running, exactly as the project publishes it — keep any release-line prefix (flagd/v0.16.1, lts-4081.3.9, api/v1.11.1), since only that line is compared. e.g. v1.36.8",
+          "type": "string"
+        },
+        "version_source": {
+          "description": "where the running version was read, e.g. daemonset/cilium image tag or a user-provided value; echoed back so the claim can be audited",
+          "type": "string"
+        }
+      },
+      "required": [
+        "project",
+        "version"
+      ],
+      "type": "object"
+    },
+    "type": [
+      "null",
+      "array"
+    ]
+  },
+  {
+    "description": "the same array JSON-encoded as a string; accepted, but send the array",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / components / items
      Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "project": {
-      "description": "project slug, e.g. envoy",
-      "type": "string"
-    },
-    "target_version": {
-      "description": "optional upgrade destination, strictly above the running version: only changes with running < version <= target are returned; a target at or below running would make that range empty and is ignored with a note",
-      "type": "string"
-    },
-    "version": {
-      "description": "the version currently running, exactly as the project publishes it — keep any release-line prefix (flagd/v0.16.1, lts-4081.3.9, api/v1.11.1), since only that line is compared. e.g. v1.36.8",
-      "type": "string"
-    },
-    "version_source": {
-      "description": "where the running version was read, e.g. daemonset/cilium image tag or a user-provided value; echoed back so the claim can be audited",
-      "type": "string"
-    }
-  },
-  "required": [
-    "project",
-    "version"
-  ],
-  "type": "object"
-}
    • removedInput schema / properties / components / type
      Removed value: -[
-  "null",
-  "array"
-]
  2. Changed4 schema fields changedv0.7.5
    • changedInput schema / properties / components / items / properties / target_version / description
      Previous value: -"optional upgrade destination, strictly above the running version: only facts with running < version <= target are returned; a target at or below running would make that range empty and is ignored with a note"New value: +"optional upgrade destination, strictly above the running version: only changes with running < version <= target are returned; a target at or below running would make that range empty and is ignored with a note"
    • changedInput schema / properties / components / items / properties / version / description
      Previous value: -"the version currently running, e.g. v1.36.8"New value: +"the version currently running, exactly as the project publishes it — keep any release-line prefix (flagd/v0.16.1, lts-4081.3.9, api/v1.11.1), since only that line is compared. e.g. v1.36.8"
    • changedInput schema / properties / detail / description
      Previous value: -"brief (default): summary + critical/high facts + one-liners for the rest; full: every fact verbatim"New value: +"brief (default): summary + the items to act on, split by bucket; full: every change verbatim"
    • changedInput schema / properties / severity_min / description
      Previous value: -"only facts at or above this severity: info|low|medium|high|critical"New value: +"only changes at or above this severity: info|low|medium|high|critical"
  3. Changed1 schema field changedv0.4.2
    • changedInput schema / properties / components / items / properties / target_version / description
      Previous value: -"optional upgrade destination: only facts with running < version <= target are returned"New value: +"optional upgrade destination, strictly above the running version: only facts with running < version <= target are returned; a target at or below running would make that range empty and is ignored with a note"
  4. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / components / items / properties / version_source
      Added value: +{
+  "description": "where the running version was read, e.g. daemonset/cilium image tag or a user-provided value; echoed back so the claim can be audited",
+  "type": "string"
+}
  5. Addedv0.3.5

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnlyHint annotation: it states that versions are compared inside the server process, that only project slugs are sent upstream, that /v1/upgrade is never called, and that running versions are not logged. It also discloses branch-aware and line-aware comparison behavior, the tracked:false no-coverage meaning, and the 50-item cap with relevant_changes_omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense; every sentence carries behavior an agent must know, and the core purpose is front-loaded. It is not formatted with bullets or section breaks, which makes it harder to scan, but there is little to no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: summary fields, bucket split, action_required vs check_config, matter_key collapsing, note flags, tracked semantics, and follow-up drill-down tools. It also anticipates common pitfalls like wrong line prefixes and target versions at or below the running version.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds critical parameter semantics: version must be passed exactly as published with its line prefix, target_version only applies when strictly above the running version, version_source is echoed as an audit trail, and severity_min filters by severity. It also explains the detail:'full' behavior and the omission cap, which the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check the user's running component versions against known changes.' It then states exactly what is returned — per-component changes from releases newer than the running version — which clearly distinguishes this stack-level check from sibling drill-down tools like get_release and changes_by_entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: use it when you have running component versions and need the upgrade path, and it explains how to shape results with detail, target_version, and severity_min. It explicitly points to alternatives at the end ('Drill down with get_release or changes_by_entity'), though it does not enumerate when list_changes or list_projects would be the better choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/garlicKim21/ratatosk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server