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

The description adds valuable behavioral context beyond annotations: it discloses the slow response time (up to 45s), specifies the source (SamacSys ComponentSearchEngine), and explains the return format (raw file contents as text). Annotations cover read-only, open-world, and idempotent hints, but the description complements these with practical constraints and data source details without contradiction.

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 and front-loaded, starting with the core purpose, followed by key details (source, scope, output format), warnings, usage guidelines, and parameter explanations. Every sentence adds value, with no redundant information, making it efficient and easy to parse.

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 (external API integration, slow operation, multiple parameters) and the presence of an output schema, the description is complete. It covers purpose, usage context, behavioral traits, parameter semantics, and output details, providing all necessary context for an agent to invoke the tool correctly without needing to rely solely on structured fields.

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 0% schema description coverage, the description fully compensates by explaining both parameters in detail: 'query' is defined as an MPN to search for with examples, and 'part_id' is described as a CSE part ID from previous results that skips search. It also clarifies the relationship ('One of query or part_id must be provided'), adding crucial semantics not in 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 tool's purpose with specific verbs ('Get', 'Downloads') and resources ('KiCad schematic symbol and PCB footprint', 'raw .kicad_sym and .kicad_mod file contents'). It distinguishes itself from siblings by specifying it works for any manufacturer's part via SamacSys ComponentSearchEngine, unlike JLCPCB-focused tools like jlc_get_part.

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

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

The description provides explicit guidance on when to use this tool ('when you specifically need KiCad symbol/footprint files') and when not to ('For checking if an EasyEDA footprint exists, use jlc_get_part instead'). It also mentions performance considerations ('slow, up to 45s response time') and prerequisites ('One of query or part_id must be provided'), offering clear alternatives and 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?

The description adds significant behavioral context beyond annotations: it discloses the slow response time ('up to 45s response time'), clarifies that no API key is required, and specifies the return format (list of parts with detailed fields). Annotations cover read-only, open-world, and idempotent hints, but the description enriches this with practical constraints and output details, providing full 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?

The description is front-loaded with purpose and key guidelines, followed by parameter and return details. Every sentence adds value—no redundancy or fluff. It efficiently conveys essential information in a well-structured manner, making it easy to parse and apply.

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 (search with performance constraints) and the presence of annotations and an output schema, the description is complete. It covers purpose, usage, behavioral traits, parameters, and returns, ensuring the agent has all necessary context without needing to rely solely on structured fields.

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 0% schema description coverage, the description compensates by explaining both parameters: 'query' is defined as 'MPN or keyword' with examples, and 'limit' specifies the range and default. It adds meaningful semantics beyond the bare schema, though it could detail format constraints (e.g., query syntax) more fully to reach a perfect score.

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 specific action ('Search SamacSys ComponentSearchEngine') and resource ('ECAD model availability and datasheets'), distinguishing it from siblings by specifying its focus on ECAD models rather than general part search or other functions. It explicitly mentions the target formats (KiCad/Eagle/Altium symbols, footprints, and 3D models), making the purpose highly specific and differentiated.

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 guidance on when to use this tool ('when you specifically need ECAD model availability or datasheets from ComponentSearchEngine') and when not to use it ('For general part search, use jlc_search instead. For EasyEDA footprint availability, use jlc_get_part'). It names specific alternative tools, offering clear context and exclusions for proper tool selection.

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 read-only, non-destructive, idempotent, and open-world behavior. The description adds valuable context beyond annotations by disclosing a 'Daily quota applies' constraint, which is critical for usage planning. No contradictions with annotations are present.

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 highly concise and well-structured: a purpose statement, usage guideline, quota warning, parameter explanation with examples, and return value summary—all in minimal sentences. Every part adds value without 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?

Given the tool's complexity (single parameter, annotations, output schema), the description is complete. It covers purpose, usage guidelines, behavioral constraints (quota), parameter semantics, and return values, with the output schema handling detailed response structure.

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 0% schema description coverage, the description fully compensates by explaining the parameter's purpose ('DigiKey part number or manufacturer PN') and providing concrete examples (e.g., '296-1395-5-ND' or 'LM358P'). This adds essential meaning not present in 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 tool's purpose with specific verbs ('Cross-reference', 'Lookup') and identifies the resource ('specific MPN on DigiKey'). It distinguishes from siblings by mentioning 'jlc_search' as an alternative for general searches, making the scope explicit.

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

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

The description provides explicit guidance on when to use this tool ('Cross-reference a specific MPN on DigiKey') versus alternatives ('Use jlc_search first for general component searches'), including a named sibling tool. This helps the agent choose appropriately based on the query type.

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?

The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate this is a read-only, non-destructive, idempotent operation, the description adds practical details about performance implications ('filtering by footprint is slower'), sorting behavior ('sorted by stock'), and response structure. It doesn't contradict annotations, which already cover the safety profile adequately.

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 and efficiently organized. It starts with a clear purpose statement, provides usage context, then documents parameters in a structured format with bullet points for enum values, and concludes with return value information. Every sentence adds value without 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?

Given the tool's complexity (6 parameters, 0% schema coverage) and the presence of an output schema, the description provides excellent contextual completeness. It fully documents all parameters, explains behavioral aspects, provides usage guidance, and describes the return structure. The output schema handles the formal return specification, allowing the description to focus on semantic understanding.

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 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains each parameter's purpose, provides examples (e.g., 'C2557'), documents defaults, enumerates valid values for library_type and has_easyeda_footprint with clear explanations, and offers practical guidance on parameter usage. This goes well beyond what the bare schema provides.

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 specific verbs ('find alternative parts similar to a given component') and resources ('searches the same subcategory for parts with better availability'). It distinguishes itself from siblings like 'jlc_get_part' or 'jlc_search' by focusing specifically on finding alternatives rather than retrieving or searching for parts generally.

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 guidance on when to use this tool ('useful when a part has low stock or you want to compare options'). It also offers specific usage advice within parameter descriptions, such as recommending 'no_fee' library type 'to find cheaper alternatives for an extended part' and noting that 'filtering by footprint is slower as it checks each alternative.'

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains the search logic for mpn ('exact match, then normalized variants, then full-text search'), specifies a stock threshold ('stock >= 10'), and mentions sorting order ('sorted by stock'), which are not captured in annotations.

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 (Args, Returns, Note), uses bullet points for readability, and every sentence adds value—no fluff. It efficiently covers parameter rules, return formats, and a practical note, making it easy to scan and understand.

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 (two parameters with conditional logic, different return formats based on input) and the presence of an output schema, the description is complete. It explains parameter requirements, search behavior, return details (including specific fields like has_easyeda_footprint), and even includes a practical note for Atopile/KiCad users, leaving no gaps for agent understanding.

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 0% schema description coverage, the description fully compensates by detailing both parameters: lcsc is defined as 'LCSC part code' with an example, and mpn is defined as 'Manufacturer part number' with examples and a thorough explanation of its search behavior. This adds significant meaning beyond the bare 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 'Get' and resource 'full details for a specific JLCPCB part', making the purpose explicit. It distinguishes from siblings like 'jlc_search' (which likely returns multiple results) and 'jlc_stock_check' (which focuses on stock), establishing a specific lookup function.

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 rules: 'One of lcsc or mpn must be provided. If both are provided, lcsc takes precedence.' It also explains when to use mpn ('Useful for finding the JLCPCB equivalent of a part from another distributor or reference design'), guiding users on parameter selection based on their needs.

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

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

The description adds valuable behavioral context beyond annotations. While annotations indicate read-only, non-destructive, and idempotent operations, the description clarifies that data is returned 'exactly as EasyEDA provides it, with no interpretation or guessing,' explains the optional 'electrical' field's rarity and possible values, and mentions the 'unverified' flag. This provides important implementation details not covered by annotations.

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 and appropriately sized. It begins with the core purpose, then explains the return format, details parameters, and provides multiple illustrative examples. Every sentence adds value - there's no redundant information, and the structure helps users quickly understand what the tool does and how to use it.

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 (fetching and returning structured pin data), the description is complete. It explains the purpose, parameters, return format with detailed field descriptions, includes important behavioral notes about data interpretation and optional fields, and provides multiple concrete examples. The presence of an output schema reduces the need to explain return values, but the description still provides valuable context about what to expect.

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 0% schema description coverage, the description fully compensates by explaining both parameters: 'lcsc: LCSC part code (e.g., "C8304"). If provided, fetches UUID automatically.' and 'uuid: EasyEDA symbol UUID directly (alternative to lcsc).' It also clarifies the relationship between them: 'One of lcsc or uuid must be provided.' This provides complete parameter semantics beyond the bare 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 tool's purpose: 'Get pin information for a component from EasyEDA symbol data.' It specifies the exact resource (component pinout) and source (EasyEDA symbol data), and distinguishes itself from siblings like 'jlc_get_part' by focusing specifically on pin information rather than general part data.

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 guidance: 'One of lcsc or uuid must be provided.' It also distinguishes this tool from alternatives by specifying it returns 'raw pin data exactly as EasyEDA provides it, with no interpretation or guessing,' which helps users understand when to use this versus other data-fetching 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?

The description adds valuable behavioral context beyond annotations: it specifies that the search is limited to 'In-stock parts only (stock >= 10)' and 'Database only indexes stock >= 10', which are not covered by annotations like readOnlyHint. It also details natural language parsing capabilities and result sorting options. However, it does not mention rate limits or authentication needs, which could be relevant for a search 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 well-structured with sections like 'Args:', 'Attribute aliases:', and 'Returns:', making it easy to navigate. It is appropriately sized for a tool with 13 parameters, but some parts (e.g., the detailed 'query' examples) could be slightly condensed without losing clarity. Overall, it is efficient but not maximally concise.

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 complexity (13 parameters, 0% schema coverage) and the presence of an output schema (implied by 'Returns:' section), the description is complete. It thoroughly explains all parameters, provides usage examples, details return values, and adds behavioral context like stock limitations. No gaps are evident for a search tool of this nature.

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 0% schema description coverage, the description fully compensates by providing detailed explanations for all 13 parameters. It includes examples for 'query', clarifies defaults (e.g., 'min_stock: Minimum stock (default 10)'), lists enum values for 'library_type' and 'sort_by', and explains complex structures like 'spec_filters' with attribute aliases. This adds significant meaning beyond the bare 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 tool's purpose as 'Fast DB search with natural language parsing and parametric filters' and specifies 'In-stock parts only (stock >= 10)', which distinguishes it from other search tools. It provides specific details about what it searches (components) and how (natural language parsing, parametric filters), making it distinct from siblings like 'jlc_stock_check' or 'jlc_get_part'.

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

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

The description provides clear context for when to use this tool: for searching components with natural language queries or parametric filters, and it specifies 'In-stock parts only (stock >= 10)'. However, it does not explicitly mention when not to use it or name alternatives among sibling tools (e.g., 'jlc_search_help' or 'jlc_find_alternatives'), which prevents a score of 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context: the precedence rule ('If both provided, subcategory takes precedence'), the sorting behavior ('sorted by part count'), and the relationship to jlc_search. No contradictions with annotations.

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 and front-loaded with the core purpose. Each sentence adds value: purpose statement, usage rules, parameter details, return values, and examples. No redundant information, and the example section efficiently demonstrates three key usage patterns.

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 (hierarchical browsing with multiple modes), the description is complete. It covers all parameter combinations, return formats for each case, and ties into the broader workflow with jlc_search. With annotations covering safety and an output schema presumably detailing return structures, no gaps remain.

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 0% schema description coverage, the description fully compensates by explaining both parameters in detail: 'category: Category name (e.g., "Connectors") or ID (e.g., 13). Lists subcategories.' and 'subcategory: Subcategory name (e.g., "MOSFETs") or ID (e.g., 2954). Lists filterable attributes.' It also clarifies precedence and provides concrete examples.

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: 'Browse categories, subcategories, and filterable attributes to help build searches.' It specifies the verb ('browse') and resources ('categories, subcategories, filterable attributes'), and distinguishes it from sibling tools like jlc_search by explaining it's for discovery rather than actual searching.

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 guidance on when to use this tool: 'Call with no args to list all categories. Pass a category to see its subcategories. Pass a subcategory to discover filterable attributes for use with jlc_search spec_filters.' It also references the sibling tool jlc_search for actual searching, creating clear 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context: it's a 'live API' for 'real-time' verification, mentions pagination behavior ('Pagination through large result sets'), and notes it's specifically for low-stock scenarios ('Parts with stock < 10 or out-of-stock parts'). It doesn't contradict annotations and provides operational context beyond them.

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 efficiently structured: purpose and guidelines upfront, followed by categorized parameter explanations and return note. Every sentence adds value—no redundancy. It's appropriately sized for a complex tool with many parameters, using bullet points and clear sections without unnecessary elaboration.

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 (14 parameters, 0% schema coverage), the description provides comprehensive guidance: clear purpose, explicit usage scenarios, detailed parameter semantics, and notes on output ('Results with pagination. Use get_part(lcsc) for full details.'). With annotations covering safety and an output schema presumably detailing returns, the description fills all necessary gaps without over-explaining 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?

With 0% schema description coverage and 14 parameters, the description carries full burden. It provides detailed semantic explanations for all parameters: examples (e.g., 'ESP32' for query), clarifications (e.g., 'default 10. Set 0 for out-of-stock parts' for min_stock), enumerations (e.g., library_type options), and usage notes (e.g., 'Category ID from search_help'). This fully compensates for the schema's lack of descriptions.

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 performs 'Real-time stock verification via live JLCPCB API' with specific verb ('verification') and resource ('stock'), distinguishing it from siblings like 'jlc_search' (faster with parametric filters) and 'jlc_get_part' (full details). It explicitly differentiates from 'jlc_search' by noting this tool is for real-time verification before orders.

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 when-to-use guidance: 'Use jlc_search first for most queries — it's faster and supports parametric filters. Only use this when you need: - Real-time stock verification before placing an order - Parts with stock < 10 or out-of-stock parts - Pagination through large result sets.' It names the alternative tool ('jlc_search') and specifies three concrete scenarios for this tool's use.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: the daily quota constraint (rate limiting) and batch lookup capability (pipe-delimited up to 10 numbers), which are not captured in annotations.

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 perfectly structured and front-loaded: the first sentence states purpose and usage guidance, the second adds behavioral constraints, then parameter and return sections provide essential details. Every sentence earns its place with zero wasted words.

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 (cross-referencing with batch capability), the description provides complete context: purpose, usage guidelines, behavioral constraints (quota), parameter semantics, and return value explanation. With an output schema present, the description appropriately focuses on what the tool does rather than return format details.

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 0% schema description coverage, the description fully compensates by explaining the part_number parameter's semantics: it accepts 'Mouser part number or manufacturer PN' with examples ('595-LM358P' or 'LM358P') and describes batch lookup syntax ('pipe-delimit up to 10 numbers'). This adds crucial meaning beyond the bare 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 specific action ('Cross-reference a specific MPN on Mouser') and resource ('MPN'), distinguishing it from siblings like 'jlc_search' for general searches and 'digikey_get_part' for other distributors. It precisely defines the tool's scope as a targeted part lookup rather than general component searching.

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 guidance on when to use this tool ('Cross-reference a specific MPN') versus alternatives ('Use jlc_search first for general component searches'), naming a specific sibling tool. It also includes a daily quota constraint that informs usage frequency decisions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context about what the tool returns (popular, well-supported options with platform compatibility info) and how results are sorted (by platform support count), which goes beyond what annotations 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?

The description is well-structured with clear sections (purpose, exclusion, question answered, parameters, returns) and every sentence adds value. It's appropriately sized for a 6-parameter tool with complex options, though slightly lengthy due to the extensive measure type list.

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 (6 parameters, 0% schema coverage) and the presence of an output schema, the description is complete. It explains all parameters thoroughly, clarifies the tool's purpose and exclusions, and describes the return format and sorting logic, making the output schema sufficient for detailed response structure.

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 0% schema description coverage, the description carries the full burden of explaining parameters. It provides comprehensive details for all 6 parameters: query usage examples, measure types with extensive list and aliases, type examples, protocol options, platform filters, and limit default. This fully compensates for the schema's lack of descriptions.

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 specific verb ('Recommend') and resource ('sensor ICs and modules'), explicitly distinguishing it from sibling tools like jlc_search for buying parts. It answers a specific question pattern: 'What sensor should I use to measure X on my platform?'

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 guidance on when to use this tool (for sensor recommendations based on measurement needs) and when not to use it ('NOT for buying parts — use jlc_search'). It names a specific alternative tool and defines the exact question this tool answers.

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