search_parts

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

With no annotations, description carries full burden. Mentions results are relevance-ranked, rows are compact for triage, output is a TOON table capped to character budget, and to page with offset when truncated. Does not mention auth or rate limits, but reasonable for a 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?

Description is two sentences, front-loaded with purpose. Efficiently communicates key behavioral points and usage guidance. Could be slightly more concise, but no wasted words.

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, so description should explain return format. Mentions TOON table capped to character budget but not fields. Does not cover error conditions or language/sortorder/facets. For 6-param tool with no output schema, some gaps remain.

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%, so description must explain parameters. It explains query, rows, offset (via pagination mention), but fails to describe language, sortorder, and include_facets. Lacks clarity on these three parameters, which could confuse usage.

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?

Description clearly states the tool searches LOINC parts and defines them as LP-coded building blocks. It distinguishes from sibling tool get_loinc by noting it returns compact results for triage and to drill into full record with get_loinc. The verb 'search' and resource 'LOINC parts' are specific.

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 you need the canonical part behind a concept, or to explore the axis vocabulary.' Provides guidance on result ranking, suggests reformulating query rather than deep-paging if top hits miss, and recommends calling get_loinc for full details. Differentiates from siblings.

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