Skip to main content
Glama
Sign In

Cloudlabels

by io.cloudlabels
OverviewDiscussionsAdmin

Get station print job

get_station_print_job
Read-onlyIdempotent

Requires print. Read one Print Station job for this organization. Pass job_id. Read only. Does not print, queue, or change the job. status is queued, printing, done, error, or expired. expired is derived when a queued job is older than 4 hours or a printing job was claimed more than 30 minutes ago, and this call does not write that. An invalid job_id is rejected. Job not found. Jobs are kept for 7 days. An older job id, an unknown job id, and a job from another organization all return Job not found. The print station may also have been disconnected, which deletes its job history. error_message is the station text after secrets and paths are removed. printer.id is the station printer id, never a CUPS queue name. next_step says whether to poll again or to stop. After a few checks with no change, stop and tell the user the job is queued or printing. They can ask for the status later. On error, quote the error text, or say the station did not give one. Do not send a new print without a new dry run and a new yes from the user. If the job expired before it was picked up, offer a new dry run of print_to_station. If it expired while printing, ask the user to check the printer before offering a new dry run. A queued job adds a hint when the station looks offline. At most 30 calls per minute for one key and one job. Does not return a PDF, a download link, a payload, or a token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>"
    },
    "name": "get_station_print_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the annotations: explains that 'expired' is derived (4h queued / 30min claimed) and not written by this call, that history is kept 7 days, that old, unknown, and cross-org ids all collapse to 'Job not found', that a disconnected station deletes job history, that error_message is sanitized, and that rate limiting is 30 calls/min per key per job. Annotations already declare readOnly/idempotent, but the description adds substantial operational context.

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 content is dense and useful but front-loading is weak — the key scoping sentence is buried after an oddly placed 'Requires print' opener. 'Job not found' outcomes are restated twice and the error/next_step guidance runs long, so several sentences could be consolidated without losing meaning.

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 single-parameter read tool with no output schema, the description covers return semantics (status values, error_message, printer.id, next_step), failure modes, retention, rate limits, and follow-up actions. An agent has everything needed to call it and interpret the result correctly.

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 0%, so the description must carry the load; it tells the agent to pass job_id and explains the consequences of an invalid, unknown, stale, or cross-organization id. It does not state the expected format of job_id (opaque string, UUID, etc.), which is the remaining gap for a single required parameter.

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?

States a specific verb and resource — read one Print Station job for this organization — and explicitly negates adjacent behaviors ('Does not print, queue, or change the job'), which separates it from the print/mutation siblings. However, it never names the closest sibling get_print_job or explains how a station job differs from a general print job, so sibling differentiation is only implicit.

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?

Gives concrete operating guidance: poll a few times, then stop and report queued/printing; on expiry, choose the remediation based on whether it expired before pickup or while printing; never reprint without a new dry run and a new yes. What's missing is a direct statement of when to call this versus get_print_job or list_print_stations.

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

All Cloudlabels toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources