Get Supplier Detail

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this: it specifies the return structure (60+ fields, including verified_dimensions breakdown), error handling ('Returns error object if supplier_id not found'), and constraints ('Unverified suppliers return "not available for public access"'). It does not contradict annotations, but could mention rate limits or auth needs for a perfect score.

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 well-structured with clear sections (PREREQUISITE, USE WHEN, RETURNS, ERRORS, CONSTRAINT, WORKFLOW) and front-loaded key information. It is appropriately sized but includes some redundancy (e.g., repeating 'Chinese apparel supplier' and the Chinese translation adds length without critical value), preventing a perfect score.

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 (detailed supplier profile), the description is highly complete: it explains the return structure in detail (60+ fields, verified_dimensions), error cases, constraints, and workflow integration. With no output schema, this compensates fully. Annotations cover safety, and the single parameter is well-documented in the schema, making the description comprehensive for agent 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 100%, with the single parameter 'supplier_id' well-documented in the schema. The description adds minimal semantics beyond this, only implying the ID comes from search results. Baseline 3 is appropriate since the schema does the heavy lifting, and the description does not add syntax or format details.

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 'get' and resource 'complete profile of a single Chinese apparel supplier by ID,' distinguishing it from siblings like search_suppliers (which lists multiple) or compare_suppliers (which compares). It specifies the scope as 'single' and 'by ID,' making the purpose explicit and distinct.

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 explicit usage guidelines: 'USE WHEN user wants full details on a specific supplier already identified from search results,' with prerequisites ('MUST first call search_suppliers or recommend_suppliers'), workflow steps, and clear exclusions ('Do not call this for multiple suppliers in a loop — use compare_suppliers instead'). It names alternatives like compare_suppliers and get_supplier_fabrics.

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