Skip to main content
Glama
garlicKim21

Ratatosk

by garlicKim21
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

list_changes

Read-only

Fetch incremental release changes for CNCF projects, filterable by project, family, and action. Page through with since cursor to maintain a current local copy.

Instructions

Incremental SYNC feed of release changes for CNCF/cloud-native projects. Ordered by seq ascending — OLDEST analyzed first, so a single page is NOT the newest data; page through with 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 list_releases or get_release (omit version for the newest) instead. Filter by project, by family (security|breaking|deprecated — what kind of thing it is) and by bucket (action|check|plan — how to act now). The routine record (bot dependency bumps and the like) is excluded by default. Two fields matter most: applies_if tells you whether an entry is yours to act on — when its targets are present, look them up in the running configuration instead of parsing the sentence; matter_key is the identity of the underlying matter across releases, which get_matter expands.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNopage size, default 20, max 200 — raise it when you are syncing a local copy, not when you are answering one question
sinceNocursor: return changes with seq greater than this
bucketNoaction|check|plan — how to act now. action applies to everyone; check only if applies_if matches your setup; plan is announced for later
familyNosecurity|breaking|deprecated — what kind of thing it is
projectNoproject slug filter, e.g. envoy, istio, cilium

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • changedInput schema / properties / limit / description
      Previous value: -"page size, default 50, max 200"New value: +"page size, default 20, max 200 — raise it when you are syncing a local copy, not when you are answering one question"
  2. Addedv0.7.5

TDQS

A4.8/5.0
Behavior5/5

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

The annotations already mark readOnlyHint=true, and the description adds substantial behavior beyond that: ascending seq order, oldest-first semantics, next_since-based pagination until null, default exclusion of routine records, and the roles of applies_if and matter_key. This gives an agent a clear model of how the feed behaves, not just what it does.

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 dense but every sentence carries information: purpose, ordering, pagination, alternatives, filter semantics, and key response fields. It is front-loaded with the core sync behavior. It could be slightly more scannable, but it is not padded or redundant.

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?

For a 5-parameter tool with no output schema and no enums, the description covers the essential context: how to page, when to stop, which filters to use, what the key response fields mean, and how to route to sibling tools. An agent has enough to invoke it correctly and interpret the response meaningfully.

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

Parameters4/5

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds meaningful value by explaining bucket as 'how to act now' with per-bucket guidance, family as 'what kind of thing it is', and limit as something to raise for syncs but not one-off questions. This goes beyond the schema's field labels.

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 precise statement: 'Incremental SYNC feed of release changes for CNCF/cloud-native projects.' It names the verb, resource, and ordering semantics, and explicitly distinguishes itself from list_releases/get_release for 'latest release' queries. This makes the tool's purpose unmistakable and clearly separate from siblings.

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

Usage Guidelines5/5

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

It explicitly says when to use the tool ('Built for keeping a local copy up to date') and when not to ('For what is the latest release... use list_releases or get_release'). It also explains pagination with since and when to stop, and clarifies filters and the default exclusion of routine records.

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

Deploy Server

Other Tools