Vibe Manufacturing

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds real behavioral value beyond that: the return shape (pass/warn/fail per check with the limit and the reason), the set of supported processes, and the unit convention for inputs.

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: purpose first, then return semantics, then the process list and unit convention. The long parameter enumeration is justified because the nested params object is free-form and undocumented elsewhere, so every token earns its place.

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 fills the gap by explaining the per-check pass/warn/fail result including limit and reason. It also covers processes and units, but says nothing about behavior on unsupported processes, missing/invalid keys, or how strictly 'typical' rules apply per process.

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 only 50% and 'params' is an additionalProperties object whose schema description merely says 'see the tool description', so the description carries most of the burden. It delivers by enumerating the expected keys and their units (thickness_mm, bend_radius_mm, draft_deg, material, etc.), though the list is explicitly non-exhaustive ('for example'), leaving some ambiguity about required vs optional keys.

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 precise verb (check) and resource (a design) plus the ruleset it validates against, and positions the tool in the workflow ('before you request quotes'). It is clearly distinguishable from a passive rules-lookup sibling such as get_design_rules.

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 phrase 'before you request quotes' gives clear timing/context for when to call it, which is more than most definitions offer. However, it never names an alternative tool (e.g. get_design_rules for raw rules, or estimate_product_cost) or states when not to use it, so it stops short of 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 only say this is a non-read-only, open-world, non-idempotent, non-destructive call; the description adds the substantive behavior: consent gating, an out-of-band e-mail confirmation click, external quote requests sent per make-part only after that click, and the returned project id/token. That is exactly the kind of side-effect and authorization detail structured fields cannot convey.

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, front-loaded with the action and outcome, with the consent gate stated before the return values. The parenthetical '(as plan_prototype)' is slightly dense but earns its place by linking to the sibling.

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 describes what comes back (project id, read token, plan) and covers the consent/confirmation workflow for a 6-parameter mutation. Minor gaps: it does not say what state the project enters afterward or how the token should be handled.

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 83%, so the schema already documents description, requester_email, user_consent and the optional fields. The description largely restates requester_email and user_consent requirements rather than adding new meaning (e.g. token handling, ship_to_country or budget_note behavior), so 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?

States a specific verb and resource ('Start a prototype project') and spells out the two-step outcome: build the sourcing plan (as plan_prototype) and then send one quote request per make-part to matched manufacturers. Naming plan_prototype inline distinguishes it from that sibling and from create_rfq, so an agent can tell them apart 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 invocation context: use it for the human you act for, it needs requester e-mail and user_consent, and nothing is sent before the confirmation click. It implicitly routes plan-only needs to plan_prototype by naming it as the plan mechanism, but there is no explicit 'use X instead when...' exclusion for create_rfq or plan_prototype.

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 cover the write/destructive/ non-idempotent profile, so the description correctly focuses on added context: manufacturers are matched, opted-in ones emailed, and quote/form/agent links are returned. It surfaces a consent precondition, which annotations cannot express. Minor gaps: no rate limits or failure semantics described.

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 sentences, front-loaded with the core action and prerequisites. The last sentence adds the important consent guard. No padding, though sentence two is somewhat dense with multiple ideas run together.

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 20-parameter write tool with no output schema, the description covers prerequisites, side effects, and the response shape (quote_readiness, missing, links). Missing detail on how matching criteria (industries, materials, certifications) affect the outcome and pagination/auth considerations.

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 45% but the schema compensates with enums and inline descriptions. The description explains the purpose of dry_run and the consent gate, but does not add anything about the many untyped parameters (finish, materials, needed_by, industries, etc.). Baseline 3 is appropriate.

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 clear verb+resource ('Create a structured request for quotation') and distinguishes itself from siblings like submit_quote or get_rfq. The distinction from submit_quote_request is not made explicit, though the two are close in intent.

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?

Names prerequisite steps (get_rfq_requirements first, upload_rfq_file for files) and a precondition that must hold before calling ('Only call after the user agreed...'). However, it does not explicitly contrast with the sibling submit_quote_request, which is the most natural alternative to mention.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds a useful convention ('All money values in USD per unit') but says nothing about how missing inputs are handled or what the computed output looks like. With annotations carrying the burden, a 3 is appropriate.

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 with the primary purpose front-loaded and the currency convention stated immediately after. No filler or repetition, though for a 10-parameter tool the brevity borders on under-specification rather than pure conciseness.

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 10-parameter computation tool with no schema descriptions, no required params, and no output schema, the description is thin. It does not clarify how missing optional inputs default, how the parameters interact, or what fields the estimate returns, leaving significant gaps an agent cannot resolve from structured data.

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?

Ten parameters with 0% schema description coverage, so the description must compensate and does not — no individual parameter is explained. Only a blanket unit convention (USD per unit) is given. Self-explanatory names (part, hardware, target_margin_percent) help somewhat, but interactions like how assembly_minutes and labor_rate_per_hour combine are 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 ('Estimate') and two concrete outputs (landed cost per unit and the price needed for a target margin) scoped to a custom product. This is far more specific than a tautology, though it does not name or contrast any sibling to reinforce the distinction.

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 phrase 'for a custom product' implies a context, but there is no explicit statement of when to use this versus alternatives, no prerequisites, and no exclusions. The agent is left to infer usage entirely from the purpose sentence.

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 readOnly=true, idempotent=true, openWorld=true, destructive=false, so the safety profile is covered. The description adds that this returns full text rather than the snippets seen in search results, which is useful, but says nothing about behavior on invalid/expired ids or rate limits.

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 sentence with the action, the resource, and the id-provenance constraint, front-loaded and free of 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?

For a one-parameter read tool with no output schema, the description of what comes back (full text of a document or profile) plus where the id originates is nearly enough. It stops short of noting failure modes or response shape, but nothing essential 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?

Schema coverage is 100% and the schema description already explains the id formats (page URL or supplier:<CC>:<domain>) from search results. The description repeats rather than extends this, so the baseline 3 is appropriate.

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 (fetch) and resource (full text of a document or manufacturer profile), and ties the input to the search workflow. It is distinguishable from search_site/search, though it doesn't explicitly frame itself against siblings like get_my_profile or get_request.

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?

'by the id returned from search' implies the prerequisite workflow (search first, then fetch), which is genuine guidance. However there is no explicit when-to-use vs when-not statement and no acknowledgement of the other get_* siblings that also retrieve records.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: results come from official registries, some entries have no website, and phone/email are published only for legal entities. Small blemish: it tells the agent to 'Use next_after' while the schema parameter is named 'after'.

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 dense sentences, front-loaded with the core purpose and scope, then return fields, then filters and paging. No sentence is filler; the parenthetical source note earns its place by establishing data provenance.

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 tool with no output schema, the description usefully enumerates the returned contact channels and the legal-entity restriction on phone/email. Remaining gaps are minor: the 'next_after' vs 'after' naming mismatch and no guidance on the limit parameter or result volume.

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?

With only 40% schema coverage, the description carries real weight: it explains country as an ISO code with examples (MX, US), names process and city as filters, and describes the paging parameter. It does not cover the limit parameter or clarify its relationship to 'after', so it stops short of fully compensating.

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 manufacturing businesses) and narrows scope to official-registry establishments, which meaningfully distinguishes it from siblings like find_suppliers and match_manufacturers. It also names the data source (INEGI DENUE), though it never explicitly contrasts itself with those siblings.

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 implies when the tool is useful by listing its filters and paging mechanism, but gives no explicit guidance on when to choose it over match_manufacturers or find_suppliers. Usage is inferable from the registry-contact framing rather than stated.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that results come from a curated 'directory' (a bounded catalog rather than open web), but says nothing about result ordering, pagination beyond the limit param, or what a match record contains.

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 purpose is front-loaded in the first sentence, followed by two dense value-format sentences. The long process enumeration earns its place because the schema supplies no enum, and there is 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?

For a 4-param, all-optional read-only search with no output schema, the description covers what the tool searches and the valid value formats. It omits any notion of what a returned supplier record contains or how results are ordered, which is a minor gap for an agent that must act on the results.

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% and the schema gives no enum for process, so the description's full enumeration of 17 process ids and the country format ('ISO code (DE) or slug (germany)') adds substantial meaning beyond the schema. It leaves the 'city' parameter completely unexplained, which keeps it short of a 5.

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 with scope: 'Find contract manufacturers in the directory by country and process.' An agent can tell it is a directory lookup rather than a cost estimate or RFQ flow, but the description never names or distinguishes itself from close siblings like match_manufacturers or find_registered_businesses.

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 — 'in the directory by country and process' suggests a browse/filter lookup, and the process list implies you must supply a known process id. There is no explicit statement of when to use this versus match_manufacturers (capability matching) or when neither country nor process is required.

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, idempotentHint, openWorldHint=false and non-destructive, so the safety profile is covered. The description adds real context the annotations cannot: these are "typical rules of thumb" and "the manufacturer's own guidelines override them," which tells the agent how much authority to grant the output.

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 dense paragraph that front-loads the resource, then the payload inventory, then the override caveat, then the omit-process behavior. Every sentence carries weight; only the tail of the process list is mildly padded.

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 takes on the burden of describing returns and does so concretely (tolerances, file formats, rules plus reasons, pre-RFQ checklist, common mistakes), while also covering the optional-parameter behavior and the trust caveat. Nothing needed to invoke or interpret the call 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?

Schema description coverage is 0%, but the single enum parameter is self-explanatory and the description supplies the semantics that matter: it clarifies that process selects one manufacturing process, gives common examples (sheet metal, CNC machining, injection molding), and defines the omitted case as "list all." That covers the optionality behavior the enum alone does not.

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 resource (design-for-manufacturing rules for one process) and enumerates the payload an agent will get back (tolerances, file formats, rules with reasons, checklist, common mistakes). It reads clearly against lookups like get_playbook_step or check_design, though it never names a sibling to draw the boundary explicitly.

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?

"Omit process to list all" gives one concrete usage decision, which is genuinely useful for the single optional parameter. Beyond that there is no when-to-use/when-not guidance and no routing to check_design (which presumably consumes these rules), so the agent must infer the workflow context.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds a genuine auth note ('needs the supplier token') and hints at return content ('allowed values for each field'), but says nothing about permissions, scope limits, or the response shape for what is an undocumented-return 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?

A single sentence with the audience and auth caveat front-loaded and zero filler. The colon-joined fragment structure is slightly awkward but costs no clarity.

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, single-parameter tool with no output schema, the description covers audience, auth need, and the nature of the returned data (stored fields and their allowed values). It is nearly sufficient, missing only an explicit contrast with update_my_profile.

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 100% and the single parameter is fully documented in the schema ('Only if your client cannot send the Authorization: Bearer header'). The description only repeats that the token may be needed, adding no syntax or format detail beyond the schema, so the baseline of 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 makes clear this reads what the directory stores about your company (a read of your own profile), reinforced by the title 'Read my profile'. The verb is only implied in the body text rather than stated ('what the directory stores'), and it does not explicitly distinguish itself from the sibling update_my_profile, so it stops short of a 5.

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 scopes the audience ('For a manufacturer's agent') and flags the supplier-token requirement, implying when this read applies. However, it never states when to use this versus update_my_profile or other profile tools, so usage is only implied.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's added value is the enumeration of returned content, which is mild but real; it says nothing about ordering, caching, or error behavior for an out-of-range step.

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 sentence, front-loaded with the verb and resource, with the return contents in a parenthetical. Zero 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 only one bounded parameter and no output schema, the description usefully enumerates the return fields (summary, explanation, checklist, related tools), compensating for the missing output schema. What is absent is any framing of what the playbook is for or how steps relate, which limits usefulness for a first-time caller.

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 100% and the single 'step' parameter already documents 'Step number 1 to 13' with min/max bounds. The description's '13 playbook steps' restates the schema bound rather than adding format or meaning beyond it, so 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?

States a specific verb (Get) and resource (playbook step), bounds the scope to 'one of the 13', and enumerates what the step contains. No sibling tool overlaps this resource, so no differentiation statement is needed, but it also never says what a 'playbook' is.

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 gives no when-to-use context: it doesn't say when an agent should fetch a playbook step, whether steps must be read in order, or whether this is a prerequisite for other tools. The only guidance is implicit in the enumerated fields.

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, idempotent, and non-destructive behavior. The description adds useful context beyond that: the token must come from create_project, and the response includes plan data and per-part-request manufacturer/quote counts.

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, front-loaded with the action and return content, followed by the required inputs. Every clause adds information and there is no redundancy.

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 simple two-parameter read tool with no output schema, the description covers what is returned and where the token comes from. It could mention error behavior when the project is missing or token is invalid, but the core call semantics are present.

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 carry parameter meaning. It explains that project_id identifies the project and that token comes from create_project, which meaningfully compensates for the undocumented schema fields, though format or expiry details are not covered.

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 ('Read') and resource ('a prototype project'), and specifies the returned content: the plan plus per-part-request manufacturer and quote counts. It is clearly distinguishable from other get_* tools by its scope, though it does not explicitly contrast itself with siblings.

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 phrase 'a prototype project you created' gives clear usage context, and the second sentence states prerequisites: project_id and the token from create_project. It does not explicitly say when not to use it or name alternatives, which keeps it from a 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 already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: the caller must be a manufacturer's agent and needs the supplier token, and it discloses the return payload's composition. No rate limits or pagination notes, but for a single-object read that is minor.

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?

Single sentence, front-loaded with the audience qualifier and the token prerequisite, then the payload contents. Dense but every clause carries information; the em-dash enumeration is efficient.

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 shoulders the burden of describing what is returned, and it does so concretely. Combined with annotations covering the safety profile and the audience/auth caveat, an agent has enough to invoke it correctly; only sibling disambiguation is left implicit.

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%: supplier_token is documented in the schema as a header fallback, and rfq_id is self-evident. The description echoes the token requirement but adds no syntax, format, or lookup guidance for rfq_id beyond what is structured. Baseline 3 is appropriate.

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 ('one request in full') and enumerates the returned contents — spec, missing items, match rationale, file links, conversation. It is clear what the tool does. It does not, however, differentiate itself from the sibling get_rfq, which an agent could easily confuse with this one.

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 audience qualifier ('For a manufacturer's agent') and the token note give implied usage context, but there is no explicit when-to-use versus alternatives such as get_rfq, get_rfq_requirements, or get_rfq_thread. The agent must infer which request-reading sibling applies.

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 cover readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds value by disclosing the auth requirement (token from create_rfq) and the scope of returned data (matches plus quotes 'received so far'). It does not discuss the token's lifetime or secrecy, so it is not fully complete.

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 short sentences, front-loaded with purpose followed by the prerequisite inputs. No redundant restatement of the name or annotations; every clause earns its place.

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 needs to convey what comes back, and it does so at a high level (matches and quotes received so far). For a simple two-parameter read tool whose safety profile is covered by annotations, this is nearly sufficient; only token handling details are 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?

Schema coverage is 0% with two parameters, so the description carries the burden and does explain both: rfq_id and the token, including where the token comes from (create_rfq). It does not explain rfq_id's format or the token's validity constraints, leaving a small 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?

States a specific verb (Read) and resource scope (matches and quotes for an RFQ), which is more informative than the bare name. It is distinguishable from siblings like get_rfq_requirements or get_rfq_thread by naming matches and quotes, though it never explicitly contrasts with them.

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?

"For an RFQ you created" implies the usage context and preconditions, but there is no explicit when-to-use guidance or naming of alternatives such as get_rfq_thread or get_rfq_requirements. Usage is inferable rather than stated.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds what the call returns -- required vs. recommended items and their accepted values -- which is behavioral content the annotations cannot provide.

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, no filler. The return description comes first and the usage constraint second, which is the correct front-loading for a prerequisite lookup.

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 explaining the return shape and does so at a high level (required/recommended items with accepted values). For a single-enum, read-only tool whose annotations cover safety, that is nearly sufficient, though the structure of the returned items is not spelled out.

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%, but the single parameter is a self-explanatory process enum with 17 industry values, so little compensation is required. The phrase "a given process" adds no meaning beyond what the enum already conveys.

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 a specific resource and its payload: the required and recommended items, with accepted values, that a factory needs in order to quote a given process. That is far more informative than a restatement of the title. It does not, however, differentiate itself from adjacent lookups such as get_design_rules or check_design.

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?

"Read this before create_rfq so the request is complete" gives an explicit ordering condition and names the sibling it feeds. There is no when-not guidance or mention of other alternatives, but the sequencing instruction is unambiguous.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description only needs to add behavioural context — and it does, clarifying the message mix returned and the delta-fetch semantics of since. It says nothing about ordering, limits, or what happens with an invalid since value.

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, front-loaded with the purpose and finishing with the one operational hint. No filler or restated title.

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 tool with no output schema and only three parameters, the description covers what the thread contains and how to page through it. Missing output shape, ordering, and pagination limits are tolerable given the readOnly annotations, but would have made it complete.

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 only 33% (only token is documented). The description meaningfully explains `since` as a last-seen message_id cursor, which is exactly the kind of detail the schema lacks, but rfq_id remains undocumented in both places. It partially compensates rather than fully.

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 ("Read the conversation of a request") and enumerates the content returned — factory answers, quotes, files, and the caller's own messages. That is enough to distinguish it from get_rfq (metadata) and send_rfq_message (write), though it never names those siblings explicitly.

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 concrete usage pattern: pass since=<last message_id> to fetch only new messages, which tells the agent this is the incremental-polling path after an initial read. It does not state when to prefer get_rfq/get_request instead, so there is a small gap, but useful context is present.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes the useful fact that records carry pros and cons, but says nothing about pagination, result counts, or exhaustive vs. curated coverage.

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 short sentences, front-loaded with the core action and no filler. The trailing category fragment is slightly abrupt but functional and earns its place by supplying the enum values.

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 zero-required-parameter, read-only list tool with no output schema, the description covers the action, the filter, and the shape of the returned content. Only the pagination/volume behavior is left unstated, which is a minor gap at this complexity.

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 100% and the single parameter is documented only as 'Optional category filter'. The description adds real value by enumerating the seven accepted category values, which the schema does not constrain via enum.

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 tools and factories') and adds what the results contain ('with pros and cons'). It does not differentiate itself from close siblings like match_manufacturers or find_suppliers, but the act itself is unambiguous.

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: browsing manufacturing tools/factories, optionally narrowed by category. There is no statement of when to prefer this over match_manufacturers or find_suppliers, and no prerequisites or exclusions.

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 cover readOnly/idempotent/non-destructive, and the description adds real value beyond them: the supplier-token auth requirement, newest-first ordering, and the shape of each returned row (readiness, answered flag, your quote, unread buyer messages). Minor tension: it says the call 'needs the supplier token' while the schema presents supplier_token as a fallback only when no Authorization header is available.

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 with the audience and auth constraint front-loaded before the payload description; nothing is wasted, though the parenthetical auth note and trailing comma-list make it slightly harder to scan than a tighter two-clause phrasing.

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 and only three params, the description does the heavy lifting by enumerating returned row contents and stating the auth path. It stops short of covering pagination/limit behavior, which is the one meaningful gap for a list endpoint.

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 description explains none of the three parameters directly. It implies a default 'open' filter but never clarifies limit or the include_answered default (which the schema says is true), leaving a small mismatch between the stated 'open requests' scope and the default behavior.

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 (list), resource (open quote requests your company was matched to), audience (manufacturer's agent), and ordering (newest first). This cleanly separates it from singleton siblings like get_request and thread-oriented tools like get_rfq_thread.

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?

Names the precondition that selects this tool — you are acting as a manufacturer's agent — which implicitly excludes buyer-side use, and states the auth requirement. It does not, however, point at alternatives such as get_request for a single request or explicitly say 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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new information beyond that: the response is scored matches carrying the reasoning, which lets the agent plan an explanation to its user. It stops short of auth, rate-limit, or ordering/confidence 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?

Two short sentences, zero filler, with the purpose front-loaded before the return-value note. Nothing is wasted.

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 9-parameter tool with 44% schema coverage and no output schema, the description covers the return shape but leaves parameter semantics and alternative-tool routing entirely unaddressed. An agent could call it, but not confidently or optimally.

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?

Nine parameters with only 44% schema description coverage, and the description says nothing about any of them. The schema's own enum values (process, materials, certifications) carry some meaning, but the description does not compensate for the undocumented half (limit, materials, industries, certifications, etc.).

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 (rank) and resource (manufacturers) scoped to a 'structured part spec', which tells an agent exactly what it gets. It does not, however, distinguish itself from siblings like find_suppliers, find_registered_businesses, or search, which an agent could plausibly confuse it with.

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 phrase 'for a structured part spec' implies a context, but there is no explicit when-to-use, when-not-to-use, or routing to the sibling tools (find_suppliers, search, find_registered_businesses). An agent has to guess which lookup tool is appropriate.

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 read-only/idempotent/non-destructive, so the 'Read-only' repetition adds little; however 'needs no e-mail' adds auth context and 'States no prices or lead times' proactively bounds the output, which annotations cannot express. No pagination or latency context, but for a planning tool that is minor.

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 and output shape, then limitations and the sibling comparison. The middle enumeration is dense but each clause carries distinct information; no filler sentences.

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 sketches the return structure (make vs buy split, integration steps, gaps, assumptions) and caps expectations (no prices/lead times). Complete enough to invoke confidently; only minor imprecision in what 'gaps and assumptions' concretely means.

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 100% with per-parameter descriptions, so the baseline is 3. The description only restates the 'product description' input and adds nothing about quantity, budget_note, or ship_to_country semantics 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?

States a specific verb ('Turn a product description into a sourcing plan') plus the exact resource, and enumerates the output components (make/buy splits, integration steps, gaps, assumptions). It also distinguishes itself from the closest sibling by contrasting 'a product rather than a single part' with create_rfq.

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 names the sequencing rule ('use it before create_rfq') and the condition that selects it ('when the user has a product rather than a single part'). Both when-to-use and the alternative are stated, not inferred.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context by stating the tool returns result ids intended for fetch, which helps the agent understand the follow-up flow.

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 scope, then query guidance, then return behavior. No redundant or filler text.

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 search tool with no output schema and rich annotations, the description is adequate: it covers scope, query hints, and the return shape. It does not mention pagination or result limits, but those are minor for this 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that mentioning a process or country produces matching manufacturers, which supplements the query parameter's semantics with intent-specific guidance.

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 gives a clear verb and scope: search the playbook, guides, tool reviews, and manufacturer directory. It tells the agent what content is covered, though it does not explicitly distinguish this from siblings like search_site or match_manufacturers.

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 clear query context: mention a process or country to get matching manufacturers, and notes that results are ids for fetch. It does not state when to prefer this over alternatives such as match_manufacturers or search_site, but the usage context is clear enough.

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, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered and the description correctly implies a closed, site-local index. It adds no further behavior — no pagination, result limits beyond the schema's 1–20, or ranking/return-shape notes — so it only meets the lower post-annotation bar.

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 front-loaded sentence naming the corpus with zero filler. It could not easily be shortened, though its brevity is also the source of the missing routing and behavior detail.

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 simple two-parameter, read-only search with a fully documented schema and no output schema, the core need is covered. The notable gap is disambiguation from the sibling 'search' tool and any hint about what results look like, which the description does not address.

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% for both parameters, so the schema fully documents 'query' as free text and 'limit' as 1–20. The description contributes no meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 (search) and the exact corpus it covers — playbook, guides, tool reviews and comparisons on vibe-manufacturing.com. That is more concrete than a generic 'search the site'. It does not, however, distinguish itself from the sibling tool named 'search', leaving the boundary between the two ambiguous.

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?

No when-to-use guidance is given. With a sibling literally called 'search' in the same server, the agent needs to know which corpus each covers; the description never states when to pick this tool over that one, nor any prerequisites.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false; the description adds the crucial human-in-the-loop workflow (draft, then send only after manufacturer confirmation) and notes the supplier-token auth path. That is meaningful behavior beyond the structured hints, though it omits rate limits or whether the message is visible externally.

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, front-loaded with the audience and auth requirement, with no filler sentences. The parenthetical and em-dash clause make it dense but 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?

With no output schema and annotations covering the safety profile, the description supplies the audience, the match precondition, file-attachment source, message kinds, and the confirm-before-send workflow. The main residual gap is what rfq_id denotes and the meaning of the 'note' kind.

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 only 20%, so the description must carry the load; it partially does by tying file_ids to upload_rfq_file and enumerating message kinds, but it omits 'note' from the enum it lists and says nothing about rfq_id or body. Two of five parameters remain effectively undocumented outside a minimal 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 names a specific verb and resource ('write to the buyer of a request you were matched to') and scopes the audience to a manufacturer's agent, so the action is unambiguous. It does not, however, distinguish itself from the sibling 'send_rfq_message', which an agent would need to disambiguate before choosing.

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 clear context for use: you must be a manufacturer's agent matched to the request, and the message may be a question, answer, or update. The 'draft it for the manufacturer and send only after they confirm' instruction adds real operational guidance, but no alternative tool is named and no when-not condition is given.

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?

Beyond the annotations, the description discloses that delivery happens by email or API (an external relay, reinforcing openWorldHint) and that the thread is persisted. This adds useful delivery/thread-persistence context. It does not cover permissions or reversibility, so it stops 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?

A single dense sentence is front-loaded with the core action and routing logic, and every clause (token roles, content kinds, attachments, relay mechanism, thread) carries information. It is efficient, though the packing makes it slightly harder to scan.

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 six parameters, the description covers direction, intent, attachments, delivery channel, and thread persistence — enough to call it correctly. Only authorization/prerequisite detail and full enum coverage are absent.

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?

With only 33% schema description coverage, the description must compensate and does partially: it explains token role semantics (buyer vs supplier), optional file_ids, and content kinds. However it omits the 'note' enum value present in the schema and says nothing about rfq_id or body, leaving gaps.

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+resource (write/send a message about an RFQ) and clarifies the dual routing model — to matched factories via a buyer token versus to the buyer via a supplier token. This distinguishes it from the generic send_message sibling by anchoring the action to an RFQ thread.

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 clear context for which token/direction to use (buyer vs supplier) and enumerates the content intents (question/answer/update). It does not, however, contrast this tool with the sibling send_message or get_rfq_thread, leaving the agent to infer which of the overlapping messaging tools to pick.

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?

Goes well beyond the annotations by disclosing concrete side effects: it replaces any existing quote from this supplier for the RFQ, appends a thread entry, and notifies the buyer by email plus an optional callback. It clarifies that repeating the call re-sends notifications, corroborating idempotentHint=false, and flags the authorization requirement.

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, side-effect and prerequisite information front-loaded before the auth caveat, with no filler. Slightly dense but every clause carries required context.

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 non-idempotent, destructive, open-world mutation with no output schema, the description covers authorization, side effects, and re-call behavior well. The main gap is parameter semantics, but the safety/behavior profile is complete enough to call 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?

With only 38% schema description coverage across 8 parameters, the description must compensate, but it only adds meaning to supplier_token (issued at company registration). Unit price, quantity, notes, lead time, and rfq_id semantics are left unexplained in both description and 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+resource (submit/answer a quote for an RFQ) and scopes the actor clearly ('for a manufacturer's agent'). An agent can distinguish this from sibling tools like submit_quote_request or create_rfq 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 preconditions — the company must have been matched to the RFQ, the supplier token is required, and 'only call with the supplier's authorization'. It does not name alternative siblings or state when not to use it, keeping it short of a 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 already declare destructiveHint=true, openWorldHint=true and non-idempotence. The description adds genuinely new behavior: a human reviews the request and replies by email, and consent is a hard gate — useful context beyond the structured hints. It stops short of saying the submission cannot be recalled or how long review takes.

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 purpose then precondition then behavior; nothing is wasted. The only slightly soft phrase is 'for the human you act for', but it carries the acting-on-behalf semantic.

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 non-idempotent, externally visible send with no output schema, the description covers the human review loop, the email reply channel, and the consent gate. Remaining gaps (what the optional country/process/quantity fields actually affect, and whether a submission is broadcast) are real but secondary.

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%, and country, process and quantity have no description anywhere. The description only reinforces the consent concept, which the schema already spells out ('true only if the user agreed to share the request with manufacturers'), so it fails to compensate for the undocumented half of the parameters.

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 gives a clear verb+resource ('Send a quote request') and scopes the recipient ('for the human you act for'). It is distinguishable from siblings like create_rfq and send_rfq_message in spirit, but it never names an alternative explicitly, leaving some overlap ambiguous.

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 states a concrete precondition: 'Only call after the user agreed that the request and email may be shared with suitable manufacturers.' That is real when-to-call guidance. It does not say when NOT to use it or which sibling (create_rfq, submit_quote) to prefer instead.

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 destructive/idempotent/readOnly=false, but the description adds substantial beyond-schema behavior: partial-update semantics ('fields you leave out keep their value'), replace-whole-field semantics for lists, and the set of fields that cannot be changed here. This is exactly the mutation context an agent needs.

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-loads the audience and auth requirement, then the field list, then the update semantics and the authorised rule. Dense but every sentence carries distinct operational value with 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?

For a 13-param destructive mutation with no output schema and near-zero schema coverage, the definition is largely complete: it covers auth, mutability, replacement semantics, and the confirmation gate. It stops short of describing the response or failure behavior, a minor gap given the otherwise thorough coverage.

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 8% (just supplier_token), yet the description names nearly every updatable field and groups them, and explains the crucial list-replacement rule ('a processes list replaces the stored list, so send the complete list'). It compensates well for the sparse schema and flags the immutable fields.

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 (update) and resource (my profile / manufacturer profile) and enumerates the exact mutable fields. It clearly differentiates from get_my_profile by being the write counterpart, and scopes the audience ('for a manufacturer's agent').

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 prerequisites (needs the supplier token) and a conditional rule for the authorised flag ('set authorised: true only after the manufacturer confirmed the change'). It does not explicitly name the read alternative or when not to call it, but the use context is well established.

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 (non-readOnly, non-destructive, non-idempotent), and the description adds genuinely useful behavior beyond them: a file_id return value, a 24-hour expiry for unused files, and explicit size ceilings (6 MB base64 / 100 MB via the POST endpoint). It does not describe error behavior or expiration cleanup semantics, so it is strong but not exhaustive.

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 and formats, and each clause carries information (formats, sizes, return value, expiry, consent constraint). It is slightly dense with nested parentheses, which mildly impairs readability but not comprehension.

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 an upload mutation with no output schema, the description covers formats, size constraints, the return value (file_id), and downstream usage plus a 24-hour expiry. Missing only edge-case behavior such as failure modes or what happens to expired files already referenced in an RFQ.

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?

With 75% schema coverage, most parameters (name, token, rfq_id) are already documented. The description compensates for the undocumented content_base64 by specifying accepted file formats and size limits, adding real meaning 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?

States a specific verb (Upload) and resource (design file) and enumerates supported formats (STEP/STP, IGES/IGS, STL, 3MF, OBJ, DXF, DWG, PDF, ZIP). An agent can immediately distinguish this from siblings like create_rfq or check_design 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 strong workflow context: the returned file_id is 'to pass in create_rfq file_ids', and it points to an alternative upload path (POST /api/v1/rfq/files) for files over 6 MB. It adds a precondition ('Only upload files the user agreed to share'), but does not explicitly name sibling tools or state when not to use this tool.

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