get-drug-by-ndc

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the input formats but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, error handling, or what the output includes (e.g., drug details, availability). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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 extremely concise and front-loaded, with three sentences that efficiently cover the tool's purpose and input handling. Every sentence adds value: the first states the purpose, the second specifies formats, and the third clarifies dash handling. There is no wasted text or redundancy.

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 the tool's complexity (a lookup with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'drug information' entails in the output, potential limitations, or how it integrates with sibling tools. For a tool with no structured output or behavioral hints, more context is needed to ensure effective use.

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 schema description coverage is 100%, with the parameter 'ndcCode' fully documented in the schema. The description adds value by reiterating the acceptable formats (e.g., 'XXXXX-XXXX, XXXXX-XXXX-XX, or without dashes'), but this doesn't provide new semantic meaning beyond what's already in the schema. This meets the baseline of 3 for high schema coverage.

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's purpose: 'Get drug information by National Drug Code (NDC).' It specifies the verb ('Get') and resource ('drug information'), and while it doesn't explicitly differentiate from siblings like 'get-drug-by-product-ndc', the focus on NDC codes provides some implicit distinction. However, it doesn't fully explain how it differs from 'get-drug-by-product-ndc', which might handle similar inputs.

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 implies usage by detailing the acceptable NDC formats, suggesting when to use this tool (for NDC-based lookups). However, it provides no explicit guidance on when to choose this over alternatives like 'get-drug-by-product-ndc' or 'get-drug-by-name', nor does it mention any exclusions or prerequisites. The context is clear but lacks comparative direction.

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