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

Goes well beyond the annotations (readOnlyHint/openWorldHint/destructiveHint) by disclosing timing expectations (1-3 minutes, 5+ for large or busy queue), that these are estimates not deadlines, the Free-plan daily cap ('trial_limit'), and the meaning of each status including that 'no_source' is only final after 'resolving' ends.

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

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

Front-loads the essential facts (free, up to 20 parts, returns immediately) and every sentence carries operational information. It is long and the status list partially repeats itself in the worked example, which costs it the top 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?

With no output schema, the description fully covers the return contract: it returns immediately with per-part status and maps each status value to the next action. Combined with timing, cap, and failure-path guidance, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the parameter is already documented, but the description still adds value by reinforcing 'MPNs or LCSC numbers only' and directing agents to resolve value-only BOM rows with search_parts first. That cross-tool guidance exceeds the schema's own note about not passing values.

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?

Opens with a specific verb and resource ('Starts background extraction for up to 20 parts at once') plus the key behavioral fact that it returns immediately. It clearly separates itself from siblings by naming check_extraction_status for polling and read_datasheet for the actual read.

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

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

Gives explicit routing: poll check_extraction_status after prefetching, resolve value-only BOM rows with search_parts first, and use request_datasheet_upload when a part is 'no_source'. It also states the accepted identifier types (MPNs or LCSC numbers only), leaving little to inference.

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