Skip to main content
Glama

Check a draft job

job_status
Read-onlyIdempotent

Use this after start_job returned a statusHandle, to see whether the homeowner has sent the job and how many bids have arrived. Returns only the stage (draft, sent, collecting_bids, picked, closed or expired), the bid count and when it last changed. Never returns bid amounts, contractor names or the job text. The handle works for 7 days. Stage expired means the one-hour link lapsed before the homeowner opened it: start again with start_job. Read-only.

Input Schema

NameRequiredDescriptionDefault
statusHandleYesThe statusHandle returned by start_job (43 characters). Expires seven days after creation.

Output Schema

NameRequiredDescriptionDefault
stageYes
bidCountYes
nextStepYesGuidance for the homeowner based on the current job stage; no action has been taken.
updatedAtYes
homeownerUrlNoInstaBids page for the homeowner to open: intake for an expired draft, or their requests for a sent, collecting_bids or picked job. Omitted for other stages or when links are unavailable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / statusHandle / description
      Added value: +"The statusHandle returned by start_job (43 characters). Expires seven days after creation."
    • addedOutput schema / properties / homeownerUrl / description
      Added value: +"InstaBids page for the homeowner to open: intake for an expired draft, or their requests for a sent, collecting_bids or picked job. Omitted for other stages or when links are unavailable."
    • addedOutput schema / properties / nextStep / description
      Added value: +"Guidance for the homeowner based on the current job stage; no action has been taken."
  2. Changed3 schema fields changed
    • addedOutput schema / properties / homeownerUrl
      Added value: +{
      +  "format": "uri",
      +  "type": "string"
      +}
    • addedOutput schema / properties / nextStep
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "stage",
      -  "bidCount",
      -  "updatedAt"
      -]New value: +[
      +  "stage",
      +  "bidCount",
      +  "updatedAt",
      +  "nextStep"
      +]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: the 7-day handle lifetime, the exact field set returned, and explicit negative guarantees (no bid amounts, contractor names or job text). The 'expired means the one-hour link lapsed before the homeowner opened it' note explains a non-obvious state transition an agent would otherwise misread.

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

Conciseness4/5

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

Front-loaded with the when-to-use clause, then the return contract, then the expiry caveat — a sensible order with no filler. Minor redundancy: 'The handle works for 7 days' and 'Read-only' duplicate what the schema and annotations already state.

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 this covers everything an agent needs: when to call it, what comes back, what deliberately does not come back, the handle lifetime, and how to recover from the expired state. An output schema exists, so no further return-value detail is required.

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 schema property already states the handle comes from start_job, is 43 characters, and expires in seven days. The description restates the origin and the 7-day expiry without adding format or validation detail beyond the schema, so the 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?

Names a specific verb and resource (check a job's status after start_job returned a statusHandle) and enumerates the exact return fields (stage, bid count, last changed), which lets an agent distinguish it from siblings like start_job or bid_checklist 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?

Gives an explicit trigger ('Use this after start_job returned a statusHandle') and an explicit recovery path for the failure case: 'Stage expired ... start again with start_job.' The alternative tool and the condition that selects it are both stated, leaving nothing to inference.

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.

Resources