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

Annotations already declare safe read-only behavior, but the description adds valuable context: uses vision AI, extracts from graphs/drawings, and warns about reliability. No 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?

Well-structured with front-loaded purpose, usage, and examples. The IMPORTANT section is valuable. Slightly verbose but still 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?

No output schema is provided, so the description should clarify the return format. It implies output via examples but lacks explicit specification of response structure, leaving some gap.

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 descriptions cover 100% of parameters, so baseline is 3. The description adds meaning by explaining image_key origin and giving concrete examples, enhancing usability.

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 specifies the tool analyzes datasheet images using vision AI, with a clear verb and resource. While it distinguishes from read_datasheet, it does not contrast with all sibling tools, so it falls 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?

Explicit when-to-use (when read_datasheet returns images) and when-not-to-use (prefer text tables for precise values), plus examples and alternatives (read_datasheet). This is exemplary.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds important behavioral context: two-tier validation (structured vs LLM fallback), potential extraction delay (30s-2min) with polling need, and result semantics (PASS/WARNING/FAIL with margins). This adds significant value beyond the 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: purpose, parameter mapping, result semantics, behavior, and when not to use. While dense with information, each sentence earns its place. It could be slightly more concise, but the clarity and completeness justify the length.

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 purpose, usage, parameter mapping, behavior, and exclusions. It mentions result semantics and the validation_method field but does not fully describe the response structure. For a tool with no output schema, this is a minor gap; however, the description is otherwise highly 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 100%, so each parameter already has a description. The description enriches meaning by providing per-component-type parameter mappings (e.g., supply_voltage=VDS for MOSFETs) and clarifying that supply_voltage is only compared against VDS(max), not used for power dissipation. This adds critical context 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 tool's purpose: 'Validate whether a component will work within your operating conditions' by comparing design parameters against datasheet limits. It provides a specific verb (validate) and resource (design fit), and is distinct from sibling tools like read_datasheet which only read raw 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 explicitly states when NOT to use the tool (power dissipation, SOA checks, passive parts) and implicitly suggests alternatives (read_datasheet, analyze_image). It provides an example call and clarifies the tool's scope, giving excellent guidance for appropriate 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 mark it as read-only and idempotent. The description adds rich behavioral context: free operation, typical extraction time (30s-2min), recommended polling interval, and detailed status values with expected actions. No contradictions.

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?

Well-structured with a brief intro, usage guidance, and a detailed status table. Slightly long but every sentence adds value. Front-loads key info efficiently.

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?

No output schema, but description covers expected response fields (status, step, elapsed seconds, document ID, error reason). All statuses are documented with actionable guidance. Given the tool's simplicity, the description is fully 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?

Single parameter 'part_numbers' with 100% schema coverage. Description adds constraint ('must be specific manufacturer part numbers, not values or descriptions') and ties status 'rejected' to invalid input, providing meaningful context 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?

Clearly states it checks extraction status of parts. The description specifies it is for polling after triggering extraction, and distinguishes it from siblings like read_datasheet and prefetch_datasheets by focusing on status retrieval.

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 tells when to use (after prefetch_datasheets or read_datasheet), polling cadence (every 5-10 seconds), and when to stop (status becomes ready/failed/etc.). Also mentions alternatives for different statuses, such as retrying or uploading.

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?

Description adds significant behavioral context beyond annotations: explains that only cached datasheets are used (no extraction triggered), validates all MPNs upfront causing whole call rejection on bad input, and details error handling. No contradiction with annotations (readOnlyHint=true, etc.).

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, when to use, behavior, constraints, example, datasheet statuses). Front-loaded with key information. While lengthy, every sentence serves a purpose, so it earns a high 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 and lack of output schema, the description thoroughly explains return values (merged provider data, cached datasheet summary, datasheet_status) and provides exhaustive detail on each datasheet status. This makes the tool fully understandable for an AI agent.

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 baseline is 3. The description adds valuable semantics: clarifies that part_numbers must be specific MPNs (not values/descriptions/reference designators), provides examples, and explains validation behavior. This justifies a score above baseline.

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: compare 2-5 electronic components side by side in a single call. It uses specific verbs and resources, and distinguishes from sibling tools like get_part_details (single part) and search_parts/find_alternative (for discovery).

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

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

Explicitly states when to use (instead of looping get_part_details), provides alternatives (search_parts, find_alternative for discovery), prerequisites (prefetch_datasheets for summaries), and important constraints (input validation, example usage).

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 annotations indicating write operations (readOnlyHint=false, destructiveHint=true), the description adds detailed behavioral context: server downloads bytes, re-hashes, validates PDF, creates records, charges fee, queues extraction. It also explains failure modes and side effects like charges only on valid PDF.

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?

Description is well-structured with sections for main action, success response, and failure modes. It is somewhat lengthy but each sentence adds value; front-loads the core action.

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?

Without an output schema, the description provides the success response fields and directs to check_extraction_status. Covers all failure modes and side effects, making it complete for a complex tool with multiple outcomes.

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 covers 100% parameters with a description for upload_token. The description adds 'Pass the upload_token you got back from the request step', reinforcing the source but not adding new semantic value 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 'Confirm a datasheet upload started via request_datasheet_upload', specifying the verb (confirm) and resource (datasheet upload). It distinguishes from siblings like request_datasheet_upload and check_extraction_status.

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 tells when to use: after request_datasheet_upload with the upload_token. Lists failure modes and how to handle each, providing clear context for when to retry or restart.

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 discloses key behavioral traits beyond annotations: filtering of eval boards, fuzzy matching for packages, fallback to semantic search, and inclusion of a 'hint' field. Annotations already indicate readOnly=true, openWorld=true, idempotent=true, and destructive=false, and the description adds significant context 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 with sections but includes a large block on datasheet status codes that is not directly relevant to the tool's primary function. This extraneous detail harms conciseness. The main behavioral description is clear and front-loaded.

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

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

Given the tool has 3 parameters and no output schema, the description provides sufficient context about the output format, behavior, and edge cases. The inclusion of datasheet status codes is excessive but does not detract from completeness. A more focused description would improve this score.

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?

All three parameters are documented in the input schema with descriptions. The description adds value by explaining the constraints options ('in_stock', 'same_package', 'jlcpcb') and providing an example usage. However, schema coverage is already 100%, so the incremental value is moderate.

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 function: 'Find alternative / second-source components for a given MPN.' It specifies the output (ranked parts with match_score and match_notes) and distinguishes it from siblings like search_parts and compare_parts through explicit usage guidance.

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 scenarios (out of stock, cheaper alternative, supply chain resilience, drop-in replacement) and when-not-to-use conditions (browsing categories or having candidates). It also includes a concrete example and explains how constraints like 'same_package' should be used.

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 readOnlyHint annotation, the description elaborates on triggering datasheet extraction via prefetch_datasheet (with 'no extra charge' assurance) and provides an exhaustive list of datasheet status values with recommended actions. No contradiction 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 front-loaded with core purpose and usage, followed by structured bullet points for datasheet statuses. While comprehensive, it is slightly lengthy; however, every sentence earns its place, making it efficient for an AI agent.

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 of datasheet states and the absence of an output schema, the description covers all necessary aspects: return contents, input validation, integration with other tools, and troubleshooting for various datasheet statuses. It leaves no critical gaps.

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%, giving a baseline of 3. The description adds significant value: it explains what constitutes a valid part_number (MPN or LCSC, not values or descriptions) and clarifies the prefetch_datasheet behavior. Provider is sufficiently documented. Minor deduction for not providing additional context on provider enumeration beyond 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 full details for a specific electronic component by manufacturer part number (MPN) or LCSC number.' It specifies what is returned (specs, pricing, stock) and distinguishes from siblings like search_parts (drill-down) and read_datasheet (separate tool for actual datasheet).

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?

Explicit guidance is given: 'Use after search_parts to drill into a specific result.' It also includes a clear list of what NOT to pass (bare values, descriptions, reference designators), preventing misuse.

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 declare readOnlyHint=true and destructiveHint=false, indicating safe read. The description adds extensive behavioral detail: non-blocking, immediate return, background extraction, retriable URL resolver for 'no_source', and status values with actions. No 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 long but well-structured: starts with core purpose and usage, then example, then parameter rules, then detailed status list. Every sentence adds value, especially given the tool's complexity (multiple statuses, retry logic). No fluff.

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 tool has one parameter and no output schema, making it moderately complex. The description covers all aspects: purpose, usage, parameter semantics, expected behavior, status values with actions, error handling, and sibling relationships. Nothing 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% with a basic description of part_numbers. The tool description goes far beyond: specifying MPN requirements (specific MPNs or LCSC numbers), prohibiting values/descriptions/reference designators, providing examples, and advising use of search_parts for resolution.

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 action: trigger background datasheet extraction for multiple parts (up to 20) non-blockingly. It distinguishes from siblings like read_datasheet and check_extraction_status by specifying when to use it (warming up datasheets before reading) and contrasting behaviors.

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 explicitly provides usage context: use for BOM warm-up before read_datasheet. It gives concrete what-not-to-pass rules (bare values, descriptions, reference designators) and alternatives like search_parts for values-only rows. It also includes retry logic and escalation paths for different statuses.

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 mark read-only, but description adds extraction latency, caching, fallback behavior, and status values with retry logic, exceeding annotation 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?

Long but well-structured with headings and bullet points; every sentence adds value, and critical information is front-loaded.

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

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

No output schema, but description explains return behavior (named section, search results with context chunks) and error handling; lacks explicit output 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?

Schema coverage is 100%, so baseline is 3. Description adds dynamic section names, required query for search, and part number constraints, providing extra 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 it reads from a component's datasheet with two modes, and the context distinguishes it from sibling search tools (search_datasheets, prefetch_datasheets) implicitly.

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 detailed when-to-use guidance: section vs search mode, first call triggers extraction, part number rules, datasheet vs reference manual distinction, and status-specific actions.

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?

Teases out the full 3-step flow, token expiration (15 min), validation rules, scoping (private), and fee structure. Adds significant context beyond annotations (which are simply readOnlyHint=false, openWorldHint=true, destructiveHint=false). No contradictions.

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 lengthy but well-structured with numbered steps and bullet points. Every section adds necessary detail. Could be slightly more concise, but clarity is not sacrificed.

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 the entire workflow, edge cases (scanned PDFs, token expiry), and return behavior (upload_url, upload_method, upload_token). No output schema exists, so the description compensates fully.

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 already covers all 4 parameters with descriptions. The description adds value by explaining how to compute expected_sha256 (using shasum) and when manufacturer is needed for disambiguation. Slightly above baseline due to practical 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 starts with a clear verb+resource: 'Request a signed URL to upload a datasheet PDF'. It specifies the exact context (missing datasheet) and distinguishes from sibling tools like confirm_datasheet_upload.

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 states when to use: when datasheet_status is 'no_source' or 'unsupported' from certain endpoints. Also provides what not to upload (dev-kit manuals, app-notes) and mentions retry logic.

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, openWorldHint, idempotentHint, and destructiveHint, covering safety and behavior. The description adds context about the semantic search nature and the limitation to previously extracted datasheets, which is useful but not extensive.

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 concise with three sentences: core purpose, usage guideline, and a clear alternative. Every sentence is informative and earns its place, with no redundancy or fluff.

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 search tool with 3 parameters and no output schema, the description adequately covers purpose, scope limitations, usage guidance, and provides an example. It could mention result format or pagination, but the provided information is sufficient for effective 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?

The input schema covers 100% of parameters with descriptions. The description provides an example query ('low-noise LDO with PSRR above 70dB') which adds a small amount of guidance, but overall the schema already 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?

The description clearly states the verb ('semantic search'), resource ('all extracted datasheets'), and scope ('across all extracted datasheets'). It also differentiates from the sibling tool search_parts by specifying that search_parts is for specific part numbers.

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 explicitly states when to use this tool ('best for broad spec-based discovery') and when not to ('only searches datasheets that have been previously extracted'). It also provides a clear alternative: 'use search_parts instead' for specific part numbers.

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 goes far beyond the annotations (readOnlyHint, etc.) by detailing parallel queries across providers, result merging, the datasheet_status field, and handling of private libraries. It provides a comprehensive table of datasheet status values and recommended actions, which is extremely helpful for the agent.

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 long but well-structured with clear sections, including a detailed datasheet status table. Every sentence adds value. It could be slightly more concise, but the information is necessary for proper tool usage.

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 (3 parameters, many sibling tools, and multiple datasheet statuses), the description is thorough. It explains the return format, how to handle each status, and references other tools. Without an output schema, the description compensates fully.

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 value by explaining that the query matches MPN, manufacturer, description, type, category, or tag for private parts. It also provides context for the 'limit' parameter regarding total results across providers, which is 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 searches for electronic components by part number, description, or keyword. It distinguishes itself from the sibling tool 'search_datasheets' by specifying that this is the best entry point for finding components, while 'search_datasheets' is for spec-based natural language discovery.

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

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

The description explicitly says 'Start here — this is the best entry point' and advises 'Best with specific part numbers or keywords'. It also tells when to use 'search_datasheets' instead. However, it does not explicitly list scenarios where this tool should be avoided, but the guidance provided is clear.

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