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

With no annotations provided, the description carries the full burden. It discloses the email uniqueness check, failure behavior on re-add, and that it returns a UUID. However, it does not mention whether the action is destructive, required permissions, or error handling for invalid 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?

The description is two sentences with no fluff. It front-loads the main action, then adds the unique behavioral detail and return value usage, making every sentence valuable.

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

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

Given 5 parameters and no output schema, the description covers key points (purpose, unique behavior, return value). However, it omits validation rules, error scenarios, and prerequisites (e.g., need for existing RFQ context). More detail on related tools or process order would improve completeness.

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

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

Schema description coverage is only 20%, with only 'categories' having a brief example. The tool description adds no parameter-level explanation beyond the schema. Critical fields like email, company_name, phone_no, person_of_contact lack any descriptive context.

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

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

The description clearly states the tool adds a new supplier to AuraVMS, distinguishes itself by noting email uniqueness check, and references a sibling tool (create_rfq) for context. This contrasts with siblings like list_rfqs or place_order which handle different domains.

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 explains that the tool should be used to add a new supplier and warns that re-adding an existing vendor fails due to email uniqueness. It also hints at the output's purpose in create_rfq. However, it does not explicitly exclude scenarios such as when list_suppliers might be a prerequisite.

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

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

With no annotations, the description bears the full burden. It discloses the key behavioral effect: suppliers can no longer submit quotes after closing. This is sufficient for a simple tool.

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

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

The description is two sentences long with no unnecessary words. The first sentence delivers the core purpose, and the second adds a key effect. It is front-loaded and 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?

For a simple tool with one parameter and no output schema, the description provides adequate context: purpose, usage trigger, and effect. It could mention possible return values or error conditions, but the simplicity reduces the need.

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 schema has 0% description coverage, and the description does not elaborate on the rfq_id parameter. However, the parameter name and schema constraints (integer, exclusiveMinimum 0) are self-explanatory. The description adds no extra meaning, so a baseline score of 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?

The description clearly states the tool's purpose with a specific verb ('close') and resource ('RFQ'), and provides context about when to close (after awards or abandonment). It distinguishes from sibling tools like create_rfq and list_rfqs.

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 explicit context for use ('once awards are placed or the sourcing round is abandoned'), which guides the agent on when to invoke. It does not explicitly list alternatives but the purpose 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?

No annotations are provided, so the description carries full burden. It clearly discloses that the tool saves a draft by default and that setting send:true emails suppliers with a quote link. This is a key behavioral trait. Missing details like the response format or error states, but the safety note is strong.

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

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

The description is very concise—two sentences and a safety note—with no wasted words. Information is front-loaded: the main purpose in the first phrase, then critical usage guidance. Every sentence serves a purpose.

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

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

Given the tool's complexity (7 parameters, no output schema), the description covers the main purpose, the crucial send parameter, and where to get supplier IDs. It does not describe the return value or item structure, but the schema covers the latter. Overall, it's sufficiently complete for correct use.

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 71%, so the schema already documents most parameters. The description adds value by reinforcing the send parameter's behavior and sourcing supplier IDs. This is adequate but not extensive, meeting the baseline for high coverage.

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

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

The description clearly states the tool creates an RFQ in AuraVMS, with the verb 'Create' and specific resource. The title adds that it creates a draft by default, distinguishing it from sibling tools like close_rfq or list_rfqs.

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

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

The description provides clear context: it defaults to draft and warns that send:true requires explicit user confirmation. It also directs users to list_suppliers or add_supplier for supplier IDs. However, it does not explicitly exclude use cases or compare to siblings.

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

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

No annotations provided, so description carries full burden. It describes the return fields (price, lead time, remarks, response_id, rank_label) and notes that L1 is price-only. No side effects or rate limits mentioned, but for a read operation this is sufficient.

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 with no wasted words. The first sentence explains the core operation, the second adds an important caveat about L1 ranking. Front-loaded with key info.

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 tool with 1 parameter and no output schema, the description is fairly complete. It explains the output fields and ranking logic. Could mention default sorting or pagination, but not necessary.

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% (1 parameter fully described). The description adds value by specifying where to obtain the rfq_item_id (from list_rfqs or create_rfq) and the exclusiveMinimum constraint, going beyond the schema.

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

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

The description clearly states the verb 'Pull' and the resource 'all supplier quotes for one RFQ line item', distinguishing it from siblings like create_rfq or place_order. It also explains the unique L1/L2/L3 ranking feature.

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?

Provides guidance on interpreting L1 ranking and reminds to weigh other factors before awarding. However, it doesn't explicitly state when to use this tool vs alternatives like list_rfqs or place_order, though it's 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?

With no annotations, the description discloses the dual behavior and data dependency but does not mention read-only nature, safety, or side effects, missing opportunities for fuller transparency.

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 concise sentences front-load the main purpose and add incremental details without waste, earning their 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?

The description covers main use cases and connections to other tools but lacks specification of return format or pagination defaults, which would be helpful given no output schema.

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 description adds meaning beyond the schema for key parameters (rfq_id and status) and compensates for low schema coverage partially, but does not detail pagination 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 clearly states the tool lists RFQs with filtering options and distinguishes its special behavior when rfq_id is provided, differentiating it from sibling get_quotes by indicating data flow.

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

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

The description provides clear context on when to use the tool with rfq_id for supplier response status and connections to get_quotes, but lacks explicit exclusions or comparisons to all siblings.

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

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

No annotations provided, so description carries full burden. It discloses that supplier emails are unique (important for add_supplier), which adds behavioral context. However, it does not explicitly state read-only nature or pagination behavior, though 'Search or list' implies it.

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 purpose, and every sentence adds value. No waste.

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

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

Given 3 optional parameters, no output schema, and no annotations, the description provides sufficient context for the tool's purpose and when to use it. Missing response details, but overall complete enough.

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%, so baseline is 3. The description adds minimal extra meaning beyond what the schema already provides (e.g., search can be name, email, category, which is in schema).

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

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

The description clearly states the verb (Search or list) and resource (suppliers in the AuraVMS account). It distinguishes itself from sibling tools by mentioning specific use cases before add_supplier and for 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 says when to use: before add_supplier (because emails are unique) and to collect UUIDs for create_rfq. This provides clear context and distinction from alternatives.

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?

Despite no annotations, the description fully discloses that this is a purchase commitment that emails a PO, refuses without confirm:true, and defaults to quoted values. This is comprehensive behavioral disclosure for a mutation tool.

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

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

The description is two sentences long and front-loaded with the main action. The second sentence packs important details but could be more structured for readability. Still, it is concise with no waste.

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

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

Given no output schema or annotations, the description covers the tool's purpose, safety, and parameter defaults well. It does not describe return values or errors, but for a mutation tool this is acceptable. Fairly 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 description coverage is 40%, but the description adds meaningful context for bought_price/bought_quantity (defaults and override use) beyond the schema. It does not elaborate on rfq_item_id, but overall it compensates partially.

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 'Place the purchase order on a winning quote' with a specific verb and resource, and it is distinct from sibling tools which are about supplier management, RFQ lifecycle, and reminders.

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

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

The description provides clear when-to-use guidance by emphasizing the need for explicit user approval and setting confirm:true. It also explains default behaviors for bought_price/bought_quantity, though it does not explicitly mention alternative tools.

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

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

With no annotations, the description fully discloses behavior: throttling to once per 24 hours and the negative effect of more frequent reminders. It also explains the effect of omitting supplier_ids.

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 main action, no redundant words. Every sentence adds value.

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

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

Given 2 parameters, no output schema, and no annotations, the description covers the action, parameter usage, and safety constraints completely.

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%; the description adds meaning by explaining that supplier_ids can be omitted to remind all non-responders, and context clarifies that rfq_id identifies the RFQ. This goes beyond the schema's basic type info.

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

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

The description clearly states it emails reminders to non-responding suppliers for an RFQ, with a specific verb (Email) and resource (reminders to suppliers), and it distinguishes from sibling tools like add_supplier or close_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?

It explains when to use the tool (to remind non-responders) and provides implicit guidance against using it too often via the throttling warning. It does not explicitly mention alternatives but the context of siblings makes usage clear.

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