Skip to main content
Glama

What changed in a product

whats_new
Read-onlyIdempotent

A product's newest releases with notes. Pass since_version (the version you run) to get only what shipped after it, with per-category change counts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoReleases to return, default 10.
productYesProduct slug or name, e.g. "next-js" or "Next.js".
since_versionNoThe version you run. Returns only the releases above it in the history, matched exactly or as the same version spelled with fewer trailing zeros. A version we do not hold is reported as a miss rather than guessed into an ordering.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoHow the product or the version was resolved.
productYes
releasesYes
returnedYes
truncatedNo
newerCountNoReleases above the pinned version, before the limit.
changeCountsNoChange items across the whole span, even when truncated.
sinceVersionNoThe version you passed.
sinceVersionFoundNoWhether that version was found in the history. False means the releases below are the latest, not the ones after yours.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint=true, establishing safety and non-mutating behavior. The description adds context about per-category change counts and the version-filtering semantics, which goes beyond the annotations. It does not contradict the annotations.

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

Conciseness5/5

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

The description is a single, focused sentence that front-loads the core purpose and then explains the key filtering parameter. Every part contributes meaning, with no filler or redundancy.

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

Completeness4/5

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

Given the presence of a rich schema, output schema, and annotations, the description is sufficient for the tool's moderate complexity. It explains the primary action and the important since_version behavior, though it omits explicit sibling differentiation, which prevents a perfect score.

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

Parameters3/5

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

The input schema provides 100% coverage with detailed descriptions for all three parameters, including the since_version matching rule. The description echoes the since_version purpose ('the version you run') but adds no new information beyond what the schema already states, so the baseline of 3 applies.

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

Purpose4/5

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

The description clearly identifies the tool as providing a product's newest releases with notes, which aligns with the title 'What changed in a product'. It does not use an explicit verb like 'Get' or 'List', and it doesn't directly distinguish itself from siblings, but the resource and intent are unambiguous.

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

Usage Guidelines3/5

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

The description explains the main usage pattern: pass since_version to filter releases shipped after a specific version. However, it doesn't provide explicit guidance on when to use this tool versus the sibling tools list_products or search_releases, nor does it mention any exclusions or alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct purpose: listing products, searching releases, and retrieving a product's latest releases. The overlap between search_releases and whats_new is manageable because descriptions clarify search vs. product-specific retrieval.

Naming Consistency3/5

Two tools follow the verb_noun pattern (list_products, search_releases), but 'whats_new' breaks the pattern with a noun-phrase name. While readable, the inconsistency in naming style is noticeable.

Tool Count5/5

Three tools is well-scoped for a release-notes tracking server. Each tool covers a distinct need without unnecessary bloat, and the count falls within the ideal 3-15 range.

Completeness5/5

The server covers the core read-only operations: discovering products, searching across release history, and getting a specific product's newest releases. No obvious gaps exist for its stated purpose, as it does not require write operations.

Resources