Skip to main content
Glama

job_status

Track an analysis job’s state (queued, running, done, failed, or cancelled), progress counts, elapsed time, and rate; use the job ID to retrieve results once finished.

Instructions

A job's state — queued, running, done, failed or cancelled — its progress ("replication k of B, comparison r -> r + 1, ok/simfail/fitfail so far" for a rank test; the replications for the IRF bands; the cells for a sweep), the elapsed time and the rate. Never a provisional number: a finished comparison is said finished, an unfinished one shows its counts only. The result itself comes from job_result once the job is done. Jobs survive the server: an id from an earlier conversation still answers here.

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": "job_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does so well: it discloses the status vocabulary, what 'progress' means per job kind, the guarantee that no provisional numbers are reported ('a finished comparison is said finished, an unfinished one shows its counts only'), and that jobs survive server restarts so stale ids still answer. It doesn't mention behavior for an unknown/failed id or whether calls are rate-limited, which keeps it off a 5.

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 state enum is front-loaded, which is right, but the middle is a single sprawling sentence freighted with nested parentheticals ('replication k of B, comparison r -> r + 1, ok/simfail/fitfail so far' ... 'the cells for a sweep'). The examples are informative but could be trimmed or moved after the operational facts.

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?

An output schema exists, so return shape need not be restated, yet the description still covers the things schema can't: non-provisional reporting, cross-server id persistence, and handoff to job_result. Only error/unknown-id behavior and polling expectations are missing, which is a minor residual gap for a one-parameter read tool.

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 description coverage is 0% and the sole parameter `job_id` is a bare string, so the description must compensate. It partially does: 'an id from an earlier conversation still answers here' establishes that the id is durable and reusable, but it never says where the id comes from (i.e., returned by the launching tool such as rank_test, sweep, irf_bands) or how invalid ids behave.

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 states a concrete verb+resource: it reports a job's state (queued/running/done/failed/cancelled), progress, elapsed time and rate. It explicitly distinguishes itself from the sibling that returns payload: 'The result itself comes from job_result once the job is done.' An agent can separate it from job_result, jobs and job_cancel without opening any schema.

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?

It names the alternative for results ('job_result once the job is done') and the condition that selects it, so polling vs. fetching results is clear. It also tells the agent it may use ids from earlier conversations. It doesn't say when to prefer `jobs` (listing) or `job_cancel`, so the routing guidance is clear but not exhaustive.

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