STEADYWRK Dispatch

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

With no annotations, the description carries full burden. It discloses that the tool is public and returns a dashboard (implying read-only). However, it does not explicitly state it has no side effects, nor does it mention any behavioral traits like rate limits or data freshness.

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

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

The description is concise, consisting of two sentences with no wasted words. The first sentence front-loads the core purpose and lists key metrics; the second adds important context about API key requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (single optional parameter, no output schema), the description is fairly complete. It covers what the tool does, its public nature, and the metrics returned. It lacks parameter details and output format, but for a simple retrieval, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only vaguely references 'selected rolling window' without enumerating the enum options or explaining their meaning. The schema already provides enum values and a default, so the description adds minimal semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the public evals dashboard with specific metrics (completion rate, NTE variance, etc.). The verb 'Return' is specific and the resource 'public evals dashboard' is well-defined. It distinguishes from siblings (dispatch.index, dispatch.order, dispatch.quote) by its unique purpose.

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

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

The description provides clear context by stating 'No API key required,' indicating it's publicly accessible. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use scenarios.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool returns 'baseline model rates' (not BLS verbatim) and that no authentication is needed. This gives sufficient behavioral context for a read-only catalog retrieval.

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

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

Two tight sentences, no filler. The purpose is front-loaded, and every sentence adds essential information (resource, data nature, access requirement).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (zero params, no output schema), the description is fully complete. It tells the user exactly what will be returned and under what conditions (no API key).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so baseline is 4. The description adds value by explaining the output: 8 verticals with rates, and the nature of those rates (model rates informed by BLS).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns 'the catalog of 8 dispatch trade verticals with baseline model rates', specifying the exact resource and scope. It distinguishes from sibling tools by focusing on the catalog/index, while siblings handle evaluations, orders, and quotes.

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

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

The description notes 'No API key required' and explains the data source, but does not explicitly state when to use this tool versus siblings like dispatch.quote or dispatch.evals. Users must infer from the purpose.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It explicitly states key behaviors: auto-matching a contractor, returning a tracked order with masked contractor reference, and a status URL. This is largely transparent, though it omits side effects, error conditions, and idempotency details.

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

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

The description is a single sentence with no wasted words. The most critical information (creation action) is front-loaded. Every clause adds value: 'Create a dispatch work order. Auto-matches... returns...'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, nested object, no output schema, no annotations), the description is underspecified. It does not explain return value structure beyond vague references, fails to describe parameter usage, and lacks guidance on prerequisites or failure modes. An agent would need additional knowledge to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to the 7 parameters. It does not explain 'trade', 'location', 'description', 'urgency', 'nte_cents', 'callback_url', or 'reference_id'. The nested object 'location' is also undocumented. The agent has only type/constraint hints, which is insufficient for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'a dispatch work order'. It distinguishes from sibling tools (dispatch.evals, dispatch.index, dispatch.quote) by specifying the creation and matching behavior. The additional detail about auto-matching and return values further clarifies the tool's unique role.

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

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

The description provides no guidance on when to use this tool versus its siblings (dispatch.evals, dispatch.index, dispatch.quote). It does not specify prerequisites, when NOT to use it, or context for selection. The agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description must carry behavioral context. It states the tool returns a quote but does not mention if it is read-only, has side effects, rate limits, or authentication requirements. The lack of detail leaves ambiguity about its behavior.

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

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

The description is a single concise sentence that efficiently lists inputs and outputs. It is front-loaded and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, a nested object, and no output schema, the description is incomplete. It does not explain the exact structure of the return value or handle edge cases. The omission of 'nte_cents' and 'description' from the description weakens its usefulness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, yet the description only enumerates 'trade + location + urgency' without explaining 'nte_cents' or 'description' parameters. It adds moderate semantic grouping but fails to clarify all parameters, especially the nested 'location' object and the purpose of 'nte_cents'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns an instant dispatch quote for field-service jobs, naming key inputs (trade, location, urgency) and outputs (contractor, cost, ETA, valid_for_minutes). It is specific and actionable, though it does not differentiate from siblings like 'dispatch.order' or 'dispatch.evals'.

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

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

There is no guidance on when to use this tool versus alternatives. It does not specify prerequisites, when not to use it, or how it compares to sibling tools like 'dispatch.order' or 'dispatch.evals'.

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