fetch_part_library

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that it writes files to the libs/ directory, that it downloads from EasyEDA, and that it writes a placeholder if geometry is unavailable, with a warning about the placeholder not matching the real part. It does not mention whether the operation is reversible or any permission requirements, but for a download/install tool, these disclosures are adequate.

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 moderately long but every sentence contributes: it states the purpose, the source of geometry, the fallback behavior, and the importance of warnings. The key information is front-loaded, with the caveat about placeholders placed at the end. It is well-structured and not padded with redundant text.

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 that there is no output schema, the description explains what the response will contain (warnings) and explicitly warns about placeholder mismatches. It covers the failure mode (EasyEDA unreachable or no geometry) and directs the user to read warnings. It does not describe the exact return format or success indicators, but for a tool of this complexity, it is sufficiently 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?

The input schema provides 100% description coverage for both parameters (lcsc and libs_dir), including examples and defaults. The description adds marginal value by reinforcing that lcsc is a C-number and that libs_dir overrides the default directory, but this is already in the schema. The description does not compensate for any missing schema details, so a baseline 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 states a specific verb (Download) and resource (symbol + footprint + 3D model for a single LCSC C-number) and explicitly mentions the install location (active project's libs/). It also distinguishes itself from siblings by focusing on a single part and sourcing from EasyEDA, making it clear what this tool does versus search or BOM resolution tools.

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 clearly implies when to use it: when you need to fetch a specific part's library by LCSC number. It also provides guidance on reading warnings when a placeholder is written, which is important for downstream actions. It does not explicitly state when not to use it or list alternative tools, but the context is sufficient for an agent to select it appropriately.

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