Skip to main content
Glama

Runtimes Status

runtimes_status
Read-onlyIdempotent

Check all language runtimes for available updates, reporting current vs latest version, package manager, and update command - without modifying anything.

Instructions

Check every language runtime for available updates (NON-MUTATING).

Reports current vs latest version per language, which package manager owns it (mise/rustup/swiftly/apt/npm/uv), and the exact command that would run.

Each entry also carries tier (registry.RELIABILITY_TIERS) — see list_languages for what tested/best_effort/plan_only mean. A current, up-to-date toolchain can still be best_effort: tier is orthogonal to whether the update check below found a newer version.

NETWORK: yes. Non-mutating refers to this machine's runtimes, not to traffic — each package manager is asked what the latest version is, and they answer by contacting their own remote index.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languagesNoComma-separated languages to check, e.g. 'python3,node,rust'; empty checks all

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / languages / description
      Added value: +"Comma-separated languages to check, e.g. 'python3,node,rust'; empty checks all"
  2. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "runtimes_statusDictOutput",
      +  "type": "object"
      +}
  3. Changed4 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / languages / title
      Added value: +"Languages"
    • addedInput schema / title
      Added value: +"runtimes_statusArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark read-only/idempotent/non-destructive, and the description goes well beyond by disclosing that the tool makes network calls, that each package manager contacts its remote index, and that non-mutating refers to local runtimes, not traffic. It also clarifies that `tier` is unrelated to update availability.

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 most important fact (non-mutating) is front-loaded in the first sentence nested in parentheses. Every subsequent sentence adds distinct value: output contents, tier semantics, network behavior, and clarification of what non-mutating means. Nothing is 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?

With an output schema and a single self-describing parameter, the description provides all necessary operational context: output fields, tier cross-reference, network behavior, and non-mutating semantics. No critical behavioral or selection information is missing.

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?

Input schema already covers the single parameter with a default and example, so the baseline is high. The description reinforces meaning by saying output is per language but adds no new parameter-level detail, which is acceptable because the schema is sufficient.

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 leads with a specific verb and resource: 'Check every language runtime for available updates'. It enumerates the output contents (current vs latest version, owning package manager, exact command, tier), which makes the tool's function unmistakable and distinguishes it from a mutating update tool.

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 clearly frames the tool as a non-mutating check of all language runtimes for available updates, which implicitly tells an agent when to use it. It does not explicitly name the alternative update_runtimes, though the phrase 'NON-MUTATING' and 'exact command that would run' strongly imply the comparison.

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