Skip to main content
Glama

Get job details

get_job
Read-onlyIdempotent

Get one job: status, exit_code, error, started_at, ended_at, cost_per_hour and cost_usd (every attempt added up; final once the job has ended), attempts, tags and group_id. Statuses: queued (waiting for a machine: queue_reason says why, no_capacity, budget, max_parallel or volume_busy, and next_attempt_at when it is tried again), starting (machine launching), running (command started), then one final state that never changes: succeeded (exit code 0), failed (non-zero exit_code, or exit_code null and error says why, such as a reached budget, no capacity within capacity_wait_minutes, or a machine that failed with no retries left), cancelled, or timed_out (an attempt ran past max_runtime_minutes). A retried job goes back to queued with attempt one higher. cost_usd covers the machine's whole time, not only the command's: from when its machine came up until it stopped, so setup before the command (pulling the image, waiting for the GPU driver, unpacking code) is included, at each machine's hourly rate (cost_per_hour is the current one's) and with every attempt added up. It is in USD to six decimal places, so a short run is not shown as $0, and while the job runs it is the cost so far. The charge on the billing page can differ slightly: machines billed by the minute are charged whole minutes, including about 30 seconds of teardown, and time some hosts report offline is not charged.

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": {
      "id": "<id>"
    },
    "name": "get_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesJob ID
workspaceNoWorkspace ID (optional: defaults to the authenticated workspace)
environmentNoEnvironment name (optional: defaults to the environment this session acts in)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / env
      Removed value: -{
      -  "description": "Environment name (optional — defaults to main)",
      -  "type": "string"
      -}
    • addedInput schema / properties / environment
      Added value: +{
      +  "description": "Environment name (optional: defaults to the environment this session acts in)",
      +  "type": "string"
      +}
    • changedInput schema / properties / workspace / description
      Previous value: -"Workspace ID (optional — defaults to authenticated workspace)"New value: +"Workspace ID (optional: defaults to the authenticated workspace)"
  2. First observed

TDQS

A3.9/5.0
Behavior5/5

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

The annotations already establish that this is a safe, read-only, idempotent operation, but the description adds substantial behavioral context beyond that. It explains the job status lifecycle, immutable final states, retry behavior, and exactly how cost_usd is accumulated and why it may differ from billing charges.

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 description is front-loaded with the core purpose and returned fields, and the status/cost details are relevant. However, it is a dense single paragraph of roughly 250 words, including billing-discrepancy details that are useful but not concise, and the status explanations would be easier to scan if structured.

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 no output schema, the description carries the burden of explaining return values, and it does so thoroughly. It covers the key fields, the full status state machine, retry behavior, cost accumulation semantics, and billing caveats, making the tool understandable without additional documentation.

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 100%, so the three parameters are already documented in the input schema. The description adds no additional meaning for id, workspace, or environment beyond what the schema provides, so the baseline of 3 applies.

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?

The description opens with a specific verb and resource: "Get one job" and enumerates the returned fields. It implicitly distinguishes itself from list_jobs by fetching a single job and from log/metric tools by focusing on status, cost, attempts, tags, and group_id. However, it does not explicitly name sibling alternatives, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the listed fields and status explanations: an agent can infer this tool is for checking a single job's state, cost, and metadata. There is no explicit guidance on when to use it versus get_job_logs, get_job_events, get_job_metrics, get_job_group, or list_jobs, and no exclusions are stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.