Steady Steel

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

Annotations flag it as a non-read-only, non-idempotent mutation, and the description adds real behavioral context beyond them: the url is bearer-access (anyone holding it can open the page) and no payment is processed through this server. It does not mention that repeat calls likely produce distinct links, which is relevant for a non-idempotent tool.

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 core action and its output (hand the buyer the url) are front-loaded in the first two clauses, followed by limits and the security caveat. It is a long conversational sentence, but almost every clause adds a constraint rather than filler.

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 no output schema, the description usefully states the return (a url to give the person) and covers preconditions, scope limits, and the no-payment caveat. It leaves open what happens on repeated calls and whether any auth scoping applies to the created page.

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 coverage is 0%, so the description carries the burden, and it does: quote ids must be ready and unexpired, count 1-10, and cover at most ten items in aggregate — semantics the bare array schema (minItems 1, maxItems 10) does not convey. It still omits the expected id format, leaving a minor gap.

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 states a concrete verb and resource: it builds a single ordering page on steadysteel.org from quoted items, with per-item buttons into the plate quoter or product order page. An agent can tell it produces an order link rather than an RFQ link, though it never explicitly names create_rfq_link as the sibling it differs from.

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?

Clear context is given: use it with one to ten quote ids that are ready and unexpired, then hand the url to the buyer. The precondition that quotes must be ready and unexpired is genuinely useful gating, but there is no explicit guidance on when to prefer this over create_rfq_link or what to do with an expired quote.

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?

Annotations only tell the agent it is non-read-only, non-idempotent and non-destructive. The description adds genuinely new behavior: PII is refused and validated out of the description field, the link expires after 30 days, and the person—not the caller—completes and sends the form while Steady Steel replies with a price. It does not clarify whether repeat calls produce new links, which is why this is a 4 rather than a 5.

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 when-to-use condition is front-loaded and every sentence carries load (eligibility, input guidance, PII refusal, expiry). It is dense but not padded; the 30-day expiry sentence is short and useful rather than filler.

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 no output schema, the description correctly covers the return value (a pre-filled quote request link) plus its lifetime and the refusal rules for PII. The only gap for completing the call is missing semantic guidance on the material and quantity parameters.

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 carries the burden. It explains the required 'description' (job in words) and implies size in inches (thickness_in), but says nothing about what 'material' or 'quantity' mean or their expected form, leaving two of four parameters semantically undocumented.

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?

States a specific verb and resource ('get a link to Steady Steel's quote request form with it filled in') and defines its exact scope as the fallback for work quote_plate and quote_product cannot price, even enumerating those cases (part from a drawing, weldment, repair, plate past the laser). An agent can distinguish this from the quoting siblings without opening their schemas.

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?

Explicit routing rule: use this when quote_plate/quote_product cannot price, with concrete examples of when that is. It also states what must NOT be sent (any person's name, email, phone, or a description containing a link/web/email/phone), and explains the downstream handoff (the person supplies contact details there).

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?

Annotations already declare readOnly, non-destructive, non-open-world, so safety is covered. The description adds genuine behavioral context beyond them: snapshot semantics ('exactly as it was priced'), the expired status condition, and a 30-day post-expiry retention window. It stops short of describing response shape or error behavior (e.g., unknown id).

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?

Three short sentences, front-loaded with the core action, then lifecycle rules. The opening clause 'Get a quote quote_plate or quote_product made' is grammatically awkward and takes a second read, which is the only waste.

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?

No output schema exists, so the description has to hint at returns; it does so by calling out the status and expires_at fields and retention. Missing details on the quote's payload and error cases, but it is sufficient to call the 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?

One parameter at 0% schema coverage, so the description carries the burden. It says only 'by its id', adding no format, length, or sourcing details beyond the schema's maxLength 64. Minimum viable for a single required identifier.

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?

'Get a quote ... made by its id, exactly as it was priced' names a specific verb and resource and clarifies that this is retrieval, not creation. It explicitly ties the resource to the siblings that create it (quote_plate / quote_product), so an agent can distinguish this read tool from the quote-producing ones 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.

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

Gives clear conditions for use and a concrete follow-up rule: once status reads expired past expires_at, ask for a new quote. It does not name an alternative retrieval path or state when not to call it, but for a single-purpose fetch tool the routing guidance is clear.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavior beyond that: it discloses the per-item return fields, the business-day unit for lead time, and the important empty-state condition when plates are not quoted online.

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?

Three tight sentences: what it returns, the ordering relationship to quote_plate, and the empty-state caveat. Every clause carries information and the return-content summary is front-loaded.

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 no output schema, the description carries the full burden of describing return values, and it does: material identity, each thickness with unit, stocked flag, and lead time in business days — plus the empty-result case. Nothing an agent needs to call and interpret this tool is missing.

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?

The tool takes zero parameters, so the baseline is 4. The description's mention of 'material id' and 'thickness_in' refers to quote_plate's inputs, not this tool's, so there is nothing further parameter-wise for it to document.

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?

States a specific verb and resource ('List the plate materials Steady Steel laser cuts') and enumerates what each entry contains: thicknesses in inches, stocked status, and lead time. It is clearly distinguishable from quote_plate and search_products, the latter being a general product search rather than a plate-material lookup.

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?

Gives an explicit sequencing rule — 'Call it before quote_plate' — and notes that quote_plate consumes the material id and thickness_in exactly as listed here. It also flags the empty-result condition ('Empty while plate is not quoted online'). It stops short of naming alternative siblings or stating when not to use it, so it lands just below a full 5.

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?

Annotations only declare the safety profile (not read-only, not open-world, not idempotent, not destructive). The description goes well beyond that, disclosing the coordinate frame (+x right, +y up, inches), what a blocked result contains and why, that amounts are CAD cents with HST listed separately, that prices are firm until expires_at, and that preview_url is the drawing to show the person.

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?

Front-loaded with the core purpose and scope, then geometry conventions, then result semantics, then the ordering hand-off — a sensible order with no filler sentences. It is dense and long, and a few sentences pack multiple constraints, but every sentence carries 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 eight parameters, deep nested schemas and no output schema, the description carries the response contract itself: blocked-with-issue, CAD cents, separate HST, expires_at, and preview_url. Combined with the ordering disclaimer, an agent has everything needed to call it, interpret the result, and route the user to checkout.

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?

Top-level parameters (material, thickness_in, quantity, quantity_options, label) carry no schema descriptions, so the description has to compensate: it fixes inches everywhere, pins quantity to 1-999, limits quantity_options to five quantities, and requires material/thickness to match list_materials exactly. The nested hole/bend/outline variants are already well documented in the schema, so the description adds most of its value at the top level.

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?

States a specific verb and resource — pricing one laser-cut flat plate with holes, slots and bends at a firm price — and names the engine behind it. It also separates itself from siblings by pointing to list_materials for material/thickness values and create_handoff_link for ordering, so an agent can tell it apart from quote_product without opening either schema.

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?

Gives concrete usage conditions: material and thickness_in must be exactly as list_materials returns them, and nothing is bought here so ordering must go through create_handoff_link. It also prescribes the recovery loop for a blocked part. It does not explicitly contrast with quote_product, so it stops short of full when/when-not routing.

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?

Annotations declare non-readOnly, non-idempotent, closed-world, so the agent knows this writes state. The description adds substantial context beyond that: currency is CAD cents before HST with HST broken out separately, freight is excluded and quoted later, and no purchase occurs. It doesn't explain whether repeated calls create duplicate quote records, which is what non-idempotent implies, so it falls short of a 5.

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?

Dense and front-loaded: pricing behavior, currency, exclusions, then the ordering handoff. Every sentence carries information, though the final sentence chains several clauses and could be split for readability.

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 no output schema, the description usefully characterizes the return values (CAD cents, HST as its own figure, freight absent). The main gap is the undocumented label/quantity_options parameters, which an agent cannot infer from the schema alone.

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 carries the full burden and it partially delivers: it explains slug and tier sourcing, the orderable-tier constraint, and the 1-50 quantity range. However, it says nothing about the label or quantity_options parameters, leaving 2 of 5 parameters undocumented anywhere.

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?

States a specific verb+resource+scope: price a catalog product at its firm unit price, distinct from sibling quote_plate (plates) and get_quote (retrieving existing quotes). The opening clause makes it immediately distinguishable from other quoting tools.

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?

Explicitly tells the agent where slug/tier come from (search_products), that only a tier marked orderable is valid, and routes ordering to create_handoff_link. It also states what this tool does NOT do (nothing is bought here), which is exactly the when-not guidance an agent needs.

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?

Annotations already establish readOnlyHint/destructiveHint=false, but the description adds real domain behavior beyond them: tiers (kit vs welded), firm unit price in CAD cents before HST, the orderable gate for quoting, and that freight is quoted separately after the order. Return shape and result limits are not described, which keeps it from a 5.

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?

Front-loaded with the core action, then compactly layered with catalog facts in four dense sentences and no filler. Slightly long for a one-parameter search but every clause conveys domain rules an agent would otherwise guess at.

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?

For a read-only search with no output schema, the description supplies the key commercial context (pricing units, tiers, orderable gate, freight follow-up) an agent needs to act on results. It omits return structure, result caps, and pagination, a minor gap for a search tool.

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 coverage is 0%, so the description carries the burden, and it does: it defines the query as words matched against product name or description and explains the null/default case ('send no query to list them all'). Only the maxLength=80 constraint is left to 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?

States a specific verb and resource ('Find the pre-designed steel products Steady Steel sells... by words in their name or description'), including the catalog location and the no-query listing behavior. It implicitly separates this catalog lookup from quoting tools, but never names a sibling (e.g., list_materials) to make the boundary explicit.

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?

Gives a clear usage rule for the empty-query case ('send no query to list them all') and frames the downstream workflow ('Only a tier marked orderable can be quoted', freight quoted after order). It does not explicitly say when to prefer this over quote_product or get_quote.

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