component_get

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

No annotations are provided, so the description carries the full behavioral burden, yet it only enumerates the shape of the returned record. It never states that this is a read-only lookup, whether it can error on an unknown name, or any side effects/auth requirements. The content list overlaps with what the output schema already conveys.

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?

One compact sentence plus a provenance clause; the resource and its content are front-loaded and nothing is padded. The slash-delimited field list is dense but readable for this domain.

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?

An output schema exists, so return values need no full explanation, and the description adequately covers the data's theme. It nonetheless omits error behavior, prerequisite state, and any read-only assurance, leaving an agent to infer them for a lookup tool with no annotations.

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 0% and the sole parameter 'name' is undocumented in the schema. The description partially compensates by stating where the name comes from (component_list), which is useful provenance, but it does not give the expected format or validity constraints for the value.

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 names a specific verb+resource: fetching the selection details (选型详情) of a single component, and enumerates the content facets (interface, address, porting requirements, top pitfall, factory verification record, wiring notes). This clearly distinguishes it from the sibling component_list, which enumerates rather than details one item. It stops short of a 5 only because it never states the operation in a single crisp clause.

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?

"name 来自 component_list" gives a concrete workflow hint (get the name from component_list first), which is genuine usage guidance. However, there is no explicit when-to-use/when-not-to-use framing and no mention of prerequisites or what to do if the component is unknown.

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