Skip to main content
Glama

status

The authoritative state of one of your jobs and everything needed to act on it: the job (current version), price, quote, window, approval (what needs the owner's yes and why: reasons, the deadline, what happens at it), commitment (who committed the booking: the owner's rule or the owner; your call is your assertion for your customer), decline (reason, code, next_actions, next_available), completion (who marked it done), cancellation (who, when, why, no fee), receipt (what was booked, from the record, with a plain text confirmation for your customer), recovery on supplier_cancelled (the job to search again with), versions, and allowed_actions / next_actions. Never the customer's details. A dead end reached in the last 24 hours (declined, expired, cancelled because the business stopped taking jobs, supplier_cancelled) carries alternatives and if_changed, kept up to 60 seconds (alternatives_worked_out_at). Every answer carries state (one of quote_incomplete, quoted, held, pending_approval, booked, completed, declined, cancelled, supplier_cancelled, expired), allowed_actions and next_actions; every error carries a code and next_actions. quote_incomplete: Not priced yet: the job needs more facts. needs says which. Nothing is held. Allowed: quote. quoted: An exact price for one exact job version, until expires_at. Nothing is held: the time is not reserved yet. Allowed: hold, quote. held: A time is reserved for this job until hold_expires_at. Book it, or cancel to let it go. Allowed: book, cancel. pending_approval: Asked to book; the owner must say yes by approval.deadline. The time stays reserved while waiting. No answer by then and the job expires and the time is released. Allowed: status, cancel. booked: The owner is committed to do this job at this price and time. Allowed: status, quote, modify, cancel. completed: The job was done. completion.source says who marked it: the owner (merchant) or CommonTape after the window ended (system). Allowed: status. declined: The owner said no. decline.reason says why; decline.next_available is the next open time when there is one. Allowed: status, quote. cancelled: Called off by the agent. The time was released. Allowed: status, quote. supplier_cancelled: Called off by the owner after it was booked. The job can be quoted again elsewhere from job. Allowed: status, quote. expired: Ran out of time: the quote passed expires_at, or the hold or the owner's answer passed its deadline. The time was released. Allowed: status, quote.

Input Schema

NameRequiredDescriptionDefault
transaction_idYestransaction_id from quote or hold

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so extensively: it defines every state, its meaning, allowed actions, deadlines, what happens at deadlines, error formats, retention of alternatives (60 seconds), and that customer details are never included. This is rich behavioral context beyond the schema.

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?

The description is front-loaded with the core purpose and uses semicolons and lists to organize a large amount of detail. However, it remains a single dense paragraph that could be more scannable with structured formatting, and some sentences are very long.

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 thoroughly documents return values, state meanings, allowed actions, and error formats. It appears complete for the tool's complexity, providing all necessary context for an agent to interpret results.

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% and the single parameter transaction_id is fully documented in the schema. The description adds no additional meaning about the parameter, so the baseline of 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?

States a specific purpose: 'The authoritative state of one of your jobs and everything needed to act on it,' and enumerates all returned components (price, quote, window, approval, etc.). Clearly distinguishes from action-oriented siblings (book, cancel, quote) by focusing on state retrieval and allowed actions.

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?

The description implies usage by detailing what the tool returns and the allowed actions per state, but never explicitly says when to use this tool versus alternatives like quote or book. No exclusions or when-not guidance are provided.

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