whobuildsit — space & defence hardware suppliers

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description earns some credit by confirming the data source is local ("suppliers in the index"), consistent with the non-open-world hint, and by listing what the answer covers. It does not describe response structure or how missing standards are handled, so it goes beyond annotations only modestly.

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?

A single dense sentence that front-loads the output contents and puts the concrete standard names early. No filler, though the elliptical fragment style is slightly less readable than a complete sentence.

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 one-parameter, read-only lookup with no output schema, the description carries enough: it tells the agent what the response will cover and that results are grounded in the index. Only minor gaps remain (input formatting, behavior on unknown standards).

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 single 'standard' parameter has no format guidance. The description partially compensates by giving real example values (AS9100D, NADCAP, ECSS, ISO 9001, MIL-STD), which helps an agent form a valid input, but says nothing about case sensitivity or whether exact strings are required.

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 resource (certification standards) and enumerates the exact content returned: what it certifies, why buyers care, requirements, and claiming suppliers. Concrete examples (AS9100D, NADCAP, ISO 9001) pin down the domain. It implicitly separates itself from siblings like search_suppliers by covering the standard itself, though it never names those alternatives.

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?

Usage is implied rather than stated: an agent can infer this is for understanding a standard's meaning and relevance. There is no explicit when-to-use versus search_parts or get_supplier, and no guidance on prerequisites or input normalization.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuine value by sketching what comes back (specs, confirmation status, supplier), which matters since there is no output schema. It says nothing about failure behavior for an unknown id or about 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?

One short sentence, front-loaded with the resource and return payload, with no filler. Every clause 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?

For a single-parameter read tool with annotations and no output schema, the description gives a rough sketch of the return shape, which is the right instinct. It stops short of covering error cases or what a missing/empty result looks like, leaving the definition only minimally 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 100%: the single id parameter is documented as 'Part id from a search result'. The description adds no further syntax, format, or sourcing detail beyond that, so the baseline 3 applies.

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 names the resource (one part) and enumerates the payload it returns: specifications, manufacturer confirmation status, and supplier. That is specific enough to separate it from search_parts, though it never names the sibling explicitly. The retrieval verb is implied rather than stated.

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 when-to-use or when-not-to-use guidance in the description itself. The only hint that this should follow a search comes from the schema's parameter note ('Part id from a search result'), not the description text. An agent must infer the search-then-fetch workflow.

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 and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it enumerates the returned fields and, unusually, discloses a negative — contact details are excluded — which prevents an agent from calling it expecting email/phone. No auth or rate-limit info, but with annotations present the bar is met.

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?

A single dense sentence that front-loads the return payload and ends with the one disqualifying caveat. Efficient, though the trailing 'use the profile URL' is slightly ambiguous about where that URL comes from and costs a clause.

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 burden of describing returns and does so field-by-field, plus flags the contact-detail omission. What remains thin is how the slug is obtained and whether this is a pre- or post-search step, which the schema only partially covers.

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?

Only one parameter with 100% schema coverage ('Supplier slug from a search result'), so the schema carries the semantics. The description adds nothing about slug format beyond implying the profile URL is the contact path, which is baseline-adequate but not additive.

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 ('Full profile' of a supplier) and enumerates what the profile contains: capabilities, certifications, categories, products. It implicitly contrasts with search_suppliers by emphasizing 'full profile' versus search results, but never names the sibling, so differentiation is inferred rather than stated.

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?

Usage is only implied: the schema's 'slug from a search result' hints that this follows a search, but the description gives no explicit when-to-use or when-not-to-use, and never names search_suppliers or get_part as alternatives. The one caveat ('contact details are not returned — use the profile URL') is output guidance, not invocation guidance.

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 this is a safe read (readOnlyHint=true) and closed-world, so the bar is lower. The description adds value the annotations don't: it discloses the hierarchical grouping and that supplier counts are included. It stops short of naming potential size/pagination behavior for a tree listing.

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 compact sentences with no filler. The return shape comes first and the usage guidance second, so the most important information 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 burden of conveying what comes back, and it does so at a useful level of detail (hierarchy plus supplier counts). Only the volume/format of the response is under-specified.

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 per the rubric. There is nothing for the description to disambiguate on the input side.

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 names the resource and its shape precisely ('the part tree (segment → assembly → component) with supplier counts'), which tells an agent exactly what this returns. It does not, however, contrast itself against siblings like search_parts or get_part, so differentiation is left to inference.

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?

It gives explicit intended use: 'Use to see what the index covers and where it has gaps.' That is a clear context for calling it, though no exclusion or alternative (e.g. 'use search_parts to find a specific part') is offered.

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 it is a non-idempotent, open-world, non-read-only call; the description goes much further by explaining the review-and-forward flow, that suppliers reply to the user directly, and that 'nothing is sent automatically'. It also states the anti-hallucination auth requirement ('never invent an email'), which is exactly the extra behavioral context annotations cannot carry.

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?

Four sentences, each earning its place: purpose first, then preconditions, then parameter guidance, then downstream behavior. Nothing is repeated from the schema and the critical user-consent instruction 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?

For a mutation tool with no output schema and 12 parameters, the description covers purpose, preconditions, the key identifiers, and the reply/delivery flow. It omits guidance on the remaining buyer-detail and compliance fields (nda, export_controlled, needed_by), though the schema itself describes several of them.

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 50%, so the description must help, and it does add real meaning for part_id/supplier_slug ('from earlier results'), buyer_email, and consent. However six parameters (quantity, buyer_name, buyer_company, buyer_country, part_id, supplier_slug) lack schema descriptions, and the description covers only two of those unknowns, leaving a genuine gap for a 12-parameter tool.

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 specific verb and resource ('Send a quote request'), names the intermediary (whobuildsit) and the recipients (suppliers who can make the part). An agent can distinguish this from sibling read tools like search_suppliers or get_part 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?

It gives a clear precondition ('Before calling, ASK THE USER for their work email and explicit consent') and directs the agent to pass a part_id or supplier_slug from earlier results when available. It stops short of naming an alternative tool or a when-not condition, so it is strong context without explicit 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuine context the annotations don't: unit normalization across psi/bar, mm, °C, GHz, and an outline of the return payload (supplier, key specs, URL). It stops short of stating result limits or empty-result 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?

Three compact sentences, front-loaded with the core purpose and followed by the highest-value behavioral detail (unit handling) and the return shape. No 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 steps in to describe the return payload. It covers query semantics and unit interpretation well, but omits result-count/pagination behavior and confirmed_only semantics, which an agent would need for full confidence.

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 67% and the two documented parameters carry their own descriptions, so baseline is 3. The description adds real semantic value by clarifying that numeric specs are unit-aware and interchangeable, which the schema does not convey, though it says nothing about limit or confirmed_only.

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 (Find) and resource (parts) plus the retrieval dimension (keyword and/or numeric specification). It is clearly distinguishable from siblings like search_suppliers and get_part.

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?

Usage is implied through the query examples and the unit-handling note, which tells the agent this is the right tool for spec-based lookups. However, it never says when not to use it or when a sibling such as get_part (for a known part) would be preferable.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful domain context (why suppliers lack product catalogues, so keyword search over capabilities is the mechanism), but says nothing about result count, pagination, ranking, or how the default limit of 10 behaves.

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 sentences, zero filler. The capability-facet enumeration comes first so the agent can pattern-match immediately, and the second sentence supplies the domain rationale that justifies the tool's existence rather than padding.

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 should carry more of the burden of explaining what comes back — it never indicates whether results are supplier summaries, whether they include certifications/contact details, or how the limit interacts with total matches. The input side is adequately covered by the schema plus description facets.

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 75%, so most parameters are self-documented. The description maps facets (process, material, certification, category, country) onto the inputs, clarifying that material/category must go through the free-text 'query' since no dedicated parameters exist — helpful, but it never mentions the 'limit' parameter or result shaping.

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 companies that can make something') and enumerates the facets searched: process, material, certification, category, country. It is clearly distinguishable from siblings like search_parts or get_supplier, which operate on parts and single suppliers rather than supplier discovery.

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 strong situational context — 'Most space hardware is made to drawing by contract manufacturers that have no product catalogue; this is how to find them' — which tells the agent exactly when this tool is the right approach. It does not, however, name alternatives (e.g. list_categories or search_parts) or state when not to use it.

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