Skip to main content
Glama

check_stack

Identify required upgrades for your running components by comparing versions against curated release facts, revealing security fixes, breaking changes, and deprecations. Versions stay local.

Instructions

Check the user's running component versions against known facts. Versions are compared LOCALLY — only project slugs are sent to the ratatosk server, running versions never leave this process. Returns, per component, the facts from releases NEWER than the running version (the upgrade path). Default is a briefing: summary counts, critical/high facts in action_required, one line each for the rest, and the same advisory fixed on several release branches collapsed into one entry. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNobrief (default): summary + critical/high facts + one-liners for the rest; full: every fact verbatim
componentsYesthe running stack to check
severity_minNoonly facts at or above this severity: info|low|medium|high|critical
Behavior5/5

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

Discloses that version comparison is local, only project slugs are sent to server, and explains the meaning of tracked:false. No annotations exist, so description carries full burden and succeeds.

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?

Description is comprehensive but somewhat lengthy; however, it is well-structured and front-loads key information. Every sentence adds value.

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?

Given three parameters and no output schema, the description fully explains the output format, edge cases, and usage context, leaving no ambiguity for an agent.

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?

Adds substantial meaning beyond schema: default detail behavior, effect of target_version and severity_min, how facts are merged in brief mode, and the significance of tracked:false.

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 clearly states it checks running component versions against known facts, distinguishing it from the sibling tool get_release by mentioning drill-down capabilities.

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?

Explicitly explains default brief mode, how to request full details, filter by severity and target version, and when to use get_release for drill-down. Provides clear context for zero-facts cases.

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