describe_feature

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

No annotations are provided, so the description carries the full burden. It discloses that the COM driver degrades to feature-tree dims and through/depth may be None. It also warns about locale sensitivity for the feature_name parameter, providing essential behavioral context beyond a simple read operation.

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 a brief intro, return fields, usage context, and parameter details. It is fairly long but each sentence adds value. Slightly more concise formatting could improve readability, but it is not verbose.

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 only one parameter, no output schema, and no annotations, the description is highly complete. It explains return values, differences in execution contexts (add-in vs COM), and parameter specifics, fully covering what the agent needs to use the tool 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?

The input schema has 0% coverage (no description for the parameter). The description compensates fully by explaining that 'feature_name' must be the exact name from get_active_part_info, verbatim, locale-sensitive, and never translated. This adds critical meaning 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 'read a built feature's definition' and lists specific return fields (name, type, found, through, depth_mm, internal, source). It is specific and distinguishes from siblings like get_feature_inventory or get_active_part_info by focusing on describing a single feature's definition.

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 context by stating it is 'used by verify_build_report to tell a through-hole from a blind one and read its depth'. It also explains the rich path vs COM driver degradation. However, it does not explicitly state when not to use this tool or mention alternatives, though the context is clear.

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