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

With no annotations, the description carries the full burden and does so well: it discloses that results are aggregate counts, not individual records, that reports are voluntary and non-causal, that common drugs accumulate more reports, and that cross-drug comparisons are unreliable. It also mentions the zero-report fallback.

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 front-loaded with the core purpose, followed by return behavior, caveats, and parameters. Each sentence adds distinct value, and the structure is easy for an agent to scan.

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, the description is complete: it explains the output format, parameter constraints, interpretation caveats, and edge-case behavior. The presence of an output schema reduces the need to describe return values in detail, and the description still covers them.

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 the description must explain the parameters, and it does: drug_name is defined as generic or brand name with an example, and top_n is given a numeric range, default, and semantic meaning. This fully compensates for the bare 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 uses a specific verb ('Summarize') and a clear resource (FDA adverse event reports for a drug), and explicitly distinguishes itself from returning individual case records. This makes it easy to differentiate from siblings like get_trial, search_drug_recalls, and get_drug_label.

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 clearly conveys when to use the tool: to get aggregate reported side-effect information for a drug. It also provides important interpretational guidance about not treating reports as causal, though it does not explicitly name sibling alternatives or state when not to use this tool.

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

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

With no annotations, the description carries the full behavioral burden. It reveals key behaviors: labels are per product, matches may be combination products or a specific manufacturer's generic, long fields are truncated and flagged, and an empty result is returned with a note when there is no match. This is meaningful transparency beyond a simple read statement.

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?

Every sentence adds value: the purpose, the scoping use case, the per-product caveat, the truncation warning, and the Args/Returns sections. It is appropriately sized for a single-parameter tool with no annotations, and the main use is front-loaded.

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?

The description covers the purpose, parameter semantics, return contents, truncation behavior, and no-match handling. It does not discuss potential errors or authentication, but for a read-only label lookup with one parameter, the provided context is nearly complete and sufficient for an agent to call it 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?

Schema description coverage is 0%, but the description fully compensates by explaining the only parameter: 'drug_name: Generic or brand name, e.g. "metformin" or "Glucophage"'. It specifies accepted forms and provides concrete examples, so an agent knows exactly what to pass.

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 opens with a specific verb and resource: 'Read the FDA-approved product label for a drug.' It then clarifies the purpose by stating what to use it for (approved indications and labeled warnings), which distinguishes it from sibling tools like get_adverse_events and search_drug_recalls.

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 phrase 'Use this for what a drug is approved to treat and what its labeled warnings say' gives clear contextual guidance for selecting the tool. It does not explicitly name alternatives or state when not to use it, but the sibling tool names and the FDA-label framing make the distinction reasonably clear.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It explicitly states the tool reads a record, returns a full set of fields, and returns a not_found error for unknown IDs. It doesn't mention auth or rate limits, but for a read operation, the error behavior and return shape are the main transparency needs. The word 'Read' signals non-mutating 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 front-loaded with a one-sentence purpose, then usage guidelines, then an Args section, then a Returns section. It is cleanly sectioned and every sentence conveys needed information without filler. It's slightly longer than two sentences, but the structured layout keeps it scannable.

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 tool with an output schema, the description covers all needed context: when to use it, what the parameter is, what is returned, and the error condition. It leaves no ambiguity about how to select or invoke the tool. The output schema handles detailed return values, so the description's summary list is sufficient.

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 provides only a type and title for nct_id, with zero description coverage. The tool description compensates fully by specifying the exact format ('NCT followed by exactly 8 digits') and providing an example ('NCT04280705'). This is indispensable for correct invocation.

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 begins with 'Read one clinical trial in full', a specific verb and resource, and immediately states the scope (eligibility). It explicitly contrasts with search_trials by saying 'Use this after search_trials when a specific trial matters', which differentiates it from the sibling tool. The return-value enumeration further clarifies its role.

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?

It provides explicit when-to-use guidance: after search_trials for a specific trial, or whenever an NCT number is mentioned. This is a clear condition that routes the agent to the correct tool. It doesn't list exclusions, but naming the alternative and the trigger condition is sufficient.

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

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

With no annotations, the description carries full burden and delivers richly. It discloses exact-match vs. candidate outcomes, explains the meaning of term types (IN, BN), and warns that candidates are not confirmed, advising user confirmation. This goes beyond simple operation statements to provide trustworthy behavior cues.

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 concise and well-structured. It opens with the core purpose, provides usage context, then details return behavior, and ends with parameter and return descriptions. Every sentence adds necessary information; nothing is redundant or irrelevant.

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 tool with an output schema, the description is complete. It explains the full decision-space (exact match vs. candidates), the interpretation of result fields, and the reliability of different match types. An agent can invoke and handle the response correctly without missing information.

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 coverage is 0% and the description compensates fully. It explains `name` with concrete examples: 'e.g. "metfromin", "Glucophage", or "metformin"'. This gives the agent exactly the format and variety expected, adding value the schema lacks entirely.

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 uses a specific verb-resource pairing: 'Resolve a drug name to its RxNorm concept, correcting spelling if needed.' It clearly differentiates this tool from siblings like search_trials and search_drug_recalls by positioning it as the entry point for drug-name resolution, not a search tool.

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?

Explicit guidance states when to use this tool: 'Use this first when a drug name is misspelled, is a brand name, or comes from user text you are unsure about.' It also directs the agent to 'pass the canonical name to the other drug tools,' establishing a workflow. This clearly separates it from alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the output structure (one entry per recall with date, product, reason, classification, status, firm), the ordering (most recent first), and the meaning of an empty result (no recalls found, not a failure). However, it does not mention potential limitations like partial matching or case sensitivity, which prevents a perfect score.

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 clear purpose statement, usage guidance, and a return description, using headings for Args and Returns. Every sentence adds value, though it is somewhat longer than strictly necessary; it remains efficient and front-loaded.

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 has an output schema, the description needn't detail return types, but it still describes the fields. It covers purpose, usage, parameters, and the empty-result case. It is complete enough for an agent to call correctly, though it could mention any error conditions or edge cases.

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 the description must compensate. It explains drug_name with examples and notes that both generic and brand names are matched, and it specifies max_results range and default. This adds significant value beyond the schema, though it could be slightly more explicit about optionality.

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 action ('Look up') and the resource ('FDA recall and enforcement reports for a drug'), and it explicitly differentiates from siblings by focusing on recalls. It also lists the specific return fields, making the tool's purpose unambiguous.

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?

It explicitly states when to use the tool ('Use this to answer whether a drug has been recalled and why') and provides an alternative ('Use normalize_drug_name first if the spelling is uncertain'). This gives clear guidance and names a sibling tool, leaving no ambiguity about selection.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses ordering ('newest registrations first'), the exact shape of each returned entry, default behavior for status, and the empty-result behavior ('empty list with a note when nothing matched'). Nothing surprising is left hidden.

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 detailed but every sentence earns its place. The purpose is front-loaded, the Args section is a clean labeled list, and the Returns section clarifies edge behavior without 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?

For a search tool with one required parameter and no annotations, the description is complete: it covers all parameters, return fields, default behavior, empty-case behavior, and how to proceed to get_trial for more detail. An agent can invoke it correctly without external context.

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 the description compensates fully. Every parameter is explained with meaning, examples, allowed values, defaults, and constraints: condition format, status choices, optional location with examples, and max_results range with default.

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 opens with a specific verb and resource: 'Find clinical trials studying a condition, newest registrations first.' It clearly distinguishes search_trials from its siblings like get_trial, and the use-case phrasing ('are there trials for X') reinforces that this is a lookup/search tool rather than a fetch-single-record tool.

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?

It explicitly says when to use this tool ('Use this to answer questions like...') and names the follow-up alternative: 'Call get_trial with an NCT number from these results for eligibility criteria and full details.' It also gives practical guidance such as preferring medical names and the meaning of status values.

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