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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds valuable context beyond annotations: it explains what the NDC is, that the tool returns the standardized 11-digit format, and that it returns active/inactive status. It also clarifies the data sources included. The description does not contradict the annotations. The only minor gap is that it doesn't mention potential failure modes (e.g., what happens if the NDC is not found), but the output schema likely covers the response structure.

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 compact and information-dense. The first sentence states the core purpose immediately. The second sentence defines the NDC format. The third sentence enumerates return fields. The final sentence gives use cases. Every sentence earns its place, and the most critical information (what the tool does) is front-loaded. No fluff or repetition of schema details.

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?

For a single-parameter lookup tool with full schema coverage, a rich output schema, and safety annotations, the description is nearly complete. It covers what the tool does, what the NDC is, what formats are accepted, what fields are returned, and when to use it. The only gap is that it doesn't explicitly state what happens when an NDC is not found or invalid, but the output schema likely handles that. It also doesn't explicitly differentiate from rxnorm.drugs.search or rxnorm.drugs.properties, but the NDC-specific focus makes that differentiation implicit.

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 100%, so the schema already documents the 'ndc' parameter thoroughly, including accepted formats (10-digit, 11-digit, hyphenated) and where to find it (drug packaging labels). The description reinforces this by explaining what an NDC is and that the tool returns the standardized 11-digit form. The description adds the context that the NDC is 'printed on every US drug package,' which helps the agent understand the parameter's real-world meaning. With only one parameter and full schema coverage, the description doesn't need to do much more.

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 ('Look up'), a specific resource ('drug product by its National Drug Code'), and the exact purpose ('retrieve its RxNorm mapping and active status'). It clearly distinguishes this from sibling tools like rxnorm.drugs.search and rxnorm.drugs.properties by focusing on NDC-based lookup. The description also enumerates the specific return fields (standardized 11-digit NDC, active/inactive status, RxCUI, concept name, data sources), leaving no ambiguity about what the tool does.

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 clear context for when to use this tool: 'Useful for medication verification, formulary checks, and cross-referencing between pharmacy systems and RxNorm.' It also explains what the NDC is and the accepted formats, which helps the agent decide if this is the right tool. However, it doesn't explicitly name alternative tools or state when NOT to use this tool (e.g., when you need to search by drug name rather than NDC code). The sibling list shows rxnorm.drugs.search and rxnorm.drugs.properties exist, but the description doesn't explicitly route to them.

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