Skip to main content
Glama

fleet_status

Read-only

Retrieve a live snapshot of every fleet printer, including connection, operational state, and temperatures; optionally group the same printers by site.

Instructions

Get live status of all fleet printers (state, temps, connection — current snapshot).

The multi-machine view is a fleet feature.  For ONE printer — which is
the single-printer experience at every tier — use ``printer_status``
(``detail="lite"`` for the cheap version), ``printer_snapshot`` or
``monitor_print``; each takes a ``printer_name`` and none of them is
tier-gated, so any machine you own can be inspected and stopped
whatever your licence.

For historical analytics (success rates, throughput), use ``fleet_analytics``.
Returns a list of printer snapshots including name, backend type,
connection status, operational state, and temperatures.  Printers
that fail to respond are reported as offline rather than raising.
A printer the person marked with ``set_machine_repair`` carries a
``repair`` block (needs repair since, or repaired at and what), and
``needs_repair_printers`` lists the ones out of service: routing does
not choose them, though they may read as idle.

Args:
    by_site: Also group the same printers by the site each one is at
        (``update_printer_site``; printers with no site fall under
        ``"unassigned"``).  When the plan includes it the answer adds
        ``sites`` (per site: ``printers``, ``count``, ``idle``, ``busy``,
        ``needs_repair``) and ``site_count``; otherwise the flat answer
        comes back with one ``note``, never a refusal.

If no printers are registered yet, the current adapter (from env config)
is auto-registered as "default".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fleet_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
by_siteNoAlso group the same printers by the site each one is at (``update_printer_site``; printers with no site fall under ``"unassigned"``). When the plan includes it the answer adds ``sites`` (per site: ``printers``, ``count``, ``idle``, ``busy``, ``needs_repair``) and ``site_count``; otherwise the flat answer comes back with one ``note``, never a refusal. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / by_site
      Added value: +{
      +  "description": "Also group the same printers by the site each one is at (``update_printer_site``; printers with no site fall under ``\"unassigned\"``).  When the plan includes it the answer adds ``sites`` (per site: ``printers``, ``count``, ``idle``, ``busy``, ``needs_repair``) and ``site_count``; otherwise the flat answer comes back with one ``note``, never a refusal. Default: false.",
      +  "title": "By Site",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint=false annotations: unresponsive printers are reported as offline rather than raising, repair-marked printers carry a repair block, repair-listed machines read as idle but are not routed to, and an unregistered fleet auto-registers the env-configured adapter as "default". These are exactly the non-obvious behaviors an agent needs before calling.

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

Conciseness3/5

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

The lead sentence is well front-loaded, but the Args section restates the by_site schema description word-for-word, which is pure duplication. The aside about tier gating and licences is useful but wordy, and the description runs long for a one-boolean read-only tool.

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?

There is no output schema, and the description fully compensates: it enumerates the returned snapshot fields, explains the by_site shape (sites, site_count, per-site counts) and the degraded flat answer with a single note instead of a refusal. Nothing needed to call it correctly or interpret the response is missing.

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?

Schema coverage is 100% and the only parameter's description in the schema is verbatim identical to the Args block in the tool description, so no meaning is added beyond the structured field. Baseline 3 is correct for a single fully-documented boolean flag.

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?

Opens with a specific verb and resource ("Get live status of all fleet printers") plus the exact fields returned (state, temps, connection) and labels it a current snapshot. It immediately demarcates fleet-wide scope from the single-printer siblings, so an agent can distinguish it from printer_status, printer_snapshot, and monitor_print without opening a schema.

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 routes three cases: fleet-wide status here, one printer via printer_status/printer_snapshot/monitor_print, and historical analytics via fleet_analytics. It even notes that the single-printer tools are not tier-gated, giving a fallback condition an agent can act on.

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