SMI Aware Assistant

Get Job

smi_get_job

Read-onlyIdempotent

Reads the status of an SMI background job. Use it with the jobId that smi_submit_deep_reports, smi_submit_exports, smi_create_deep_report or smi_create_export return when a large batch is still running, to read its outcome. Returns status (pending | processing | completed | failed), a terminal flag, and failedIds with an error when the job failed. While a batch submission job is pending or processing, poll with bounded attempts and backoff, and stop as soon as terminal is true. A release job (type deep_report_release or export_release) stays pending until that report is released, which can take days: do not poll it in a loop. Tell the user they will be notified when the report is released.

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": {
      "jobId": "<jobId>"
    },
    "name": "smi_get_job"
  }
}

Input Schema

Name	Required	Description	Default
`jobId`	Yes	Job id returned by smi_submit_deep_reports, smi_submit_exports, smi_create_deep_report or smi_create_export (the batch job id or one of the per-report release job ids).

Output Schema

Name	Required	Description	Default
`type`	Yes
`error`	Yes
`jobId`	Yes
`result`	Yes
`status`	Yes
`terminal`	Yes
`failedIds`	Yes
`webhookStatus`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial context beyond them: the returned status vocabulary (pending | processing | completed | failed), the terminal flag, failedIds plus error on failure, and the crucial timing asymmetry between batch and release jobs. That is exactly the operational behavior an agent cannot get from the annotations.

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?

Front-loaded with the purpose, then immediately the sourcing of jobId, then the return shape, then polling policy. Every sentence carries operational weight; nothing is padding despite the density.

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 an output schema, the description covers purpose, provenance of the id, return semantics, and the polling pitfalls that would otherwise cause an agent to spin on release jobs for days. Nothing an agent needs in order to call it correctly 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 single jobId parameter is already fully documented in the schema, including that it may be a batch job id or a per-report release job id. The description restates the same provenance without adding syntax or format detail, so baseline 3 applies.

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 opens with a specific verb+resource ("Reads the status of an SMI background job") and makes clear this is a status check, not a report fetch, distinguishing it implicitly from siblings like smi_get_deep_report and smi_get_export. It also names exactly which tools produce the jobId, so the agent can trace the call chain.

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?

Guidance is explicit and conditional: use it for large batches still running, poll with bounded attempts and backoff, stop when terminal is true, and do NOT poll release jobs in a loop because they can stay pending for days. It even supplies the alternative behavior for the release case (inform the user they'll be notified).

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

All SMI Aware Assistant tools Inspect

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

Need Help?