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

Without annotations, the description carries the full burden of behavioral disclosure. It states the tool returns clearance decisions and classification details, suggesting a read-oriented operation, but does not disclose potential rate limits, authentication requirements, or behavior when no results are found. A score of 3 reflects adequate but not thorough transparency.

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 two sentences with no unnecessary words. The first sentence conveys the core purpose and database, and the second lists search fields and output. It is front-loaded and efficient.

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?

With 8 parameters fully described in the schema and no output schema, the description adequately explains the tool's purpose and return type. It could briefly mention pagination (skip/limit) but this is already in the schema. Overall, the context is sufficient for selecting the tool.

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 baseline is 3. The description mentions specific search criteria (device name, applicant, product code, etc.) but does not add meaning beyond the schema's parameter descriptions. No additional semantic context is provided.

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 searches the FDA 510(k) premarket notification database for medical device clearances, specifying searchable fields (device name, applicant, product code, etc.) and return content (clearance decisions and classification details). This explicitly differentiates it from sibling tools like search_device_adverse_events or search_device_classifications.

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 when to use the tool (searching for 510(k) clearances) but does not provide explicit guidance on when to use alternatives, prerequisites, or when not to use it. No exclusions or alternative recommendations are given.

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 disclose behavioral traits. It states the tool returns device details, event descriptions, and patient outcomes, and lists filterable parameters. However, it omits information about data source freshness, rate limits, pagination behavior beyond what schema provides, or any side effects. This is adequate but not comprehensive.

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?

Two sentences, front-loaded with purpose and key capabilities. Every sentence adds value—no redundant or filler content.

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 9 parameters, no output schema, and no annotations, the description covers the main purpose and typical use cases. It mentions the key return fields (device details, event descriptions, patient outcomes) and lists major filtering dimensions. Minor omission: does not indicate that event type enum includes 'Other' (though schema covers it). Overall sufficient for an agent to understand scope.

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 baseline is 3. The description adds minor narrative context by grouping parameters (e.g., 'by device name, brand, manufacturer...'), but does not provide additional semantics beyond the schema's own descriptions. No new parameter constraints or format details are added.

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 it searches the FDA MDR database for device adverse events, listing specific searchable criteria (device name, brand, manufacturer, event type, date) and mentions retrieving a specific report by reportNumber. It distinguishes from sibling tools (e.g., drug adverse events, other device searches) by specifying 'device' and 'adverse events'.

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 for finding device adverse events, but does not provide explicit guidance on when to use this tool versus alternatives like search_device_recalls or search_device_510k. No 'when not to use' or comparison with siblings is given.

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?

Without annotations, the description carries full burden. It adds context about class risk levels but does not disclose pagination behavior (skip/limit), result ordering, error handling, or any response format details. The description provides basic functionality but not deeper behavioral traits.

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 two sentences long with no wasted words. The first sentence immediately states the purpose and the second adds helpful risk classification context. It is front-loaded and efficient for an AI agent to parse.

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 7 optional parameters, no output schema, and no annotations, the description lacks information on how multiple search criteria interact, what the output structure looks like, and pagination behavior. It covers the basic search intent but leaves gaps that could affect agent usage.

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 already describes all 7 parameters with clear descriptions (100% coverage). The description merely lists the fields without adding new meaning, examples, or constraints beyond what the schema provides. The class risk explanation is also present in the schema's deviceClass description, so no additional value.

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 searches the FDA medical device classification database and lists specific searchable fields (name, class, specialty, product code, regulation number). It explains the risk levels for classes. The name and sibling tools (e.g., search_device_510k) make the distinct purpose obvious.

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 for classification lookups by specifying the database and fields, but it does not explicitly state when to use this tool over siblings like search_device_recalls or search_device_adverse_events. No exclusion criteria or context-dependent guidance is provided.

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?

No annotations are provided, so the description must carry the full burden. It explains classification severity but does not disclose pagination behavior, output format, sorting, rate limits, or data retrieval limits beyond the schema. The agent lacks critical behavioral context.

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 two focused sentences with no redundancy. The first sentence states the core purpose, the second lists key searchable fields. Every sentence earns its place.

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?

With no output schema, the description should explain what the tool returns (e.g., recall reports, counts). It does not mention return structure, pagination, or result format. For a search tool with 8 parameters and no output schema, this is insufficient.

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 baseline is 3. The description only enumerates fields already described in the schema without adding new semantic detail (e.g., date format clarification or pagination behavior). It adds minimal value 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 searches FDA medical device recall and enforcement reports, listing specific searchable fields (company, product, classification, status, date). This distinguishes it from sibling tools like search_device_510k or 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 description implies usage by listing searchable fields but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance. No exclusion criteria or sibling differentiation is mentioned.

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 is the sole source of behavioral information. It discloses return content (patient demographics, drug details, reactions) but omits rate limits, authentication needs, or restrictions. The tool is clearly read-only, but this is not explicitly stated.

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?

Three sentences efficiently convey purpose, parameters, and return values. No unnecessary words; all sentences add value. Front-loaded with the main action.

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 no output schema and no annotations, the description adequately covers return fields. However, it does not mention pagination behavior (skip, limit) or date format specifics, which are in the schema but could be highlighted for completeness.

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?

Input schema has 100% coverage with descriptions for all 9 parameters. The description adds a summary narrative grouping parameters (e.g., 'by drug name, reaction type, manufacturer') but does not provide additional detail beyond the schema. Baseline 3 is appropriate.

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 it searches FAERS for drug safety reports, specifying key parameters (drug name, reaction, manufacturer, date range, seriousness) and the ability to retrieve by safetyReportId. It distinguishes from sibling tools by focusing on drug adverse events, as seen in sibling names like 'search_device_adverse_events'.

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 for drug adverse events but does not explicitly state when to use this tool versus alternatives like 'search_device_adverse_events'. No when-not-to-use or exclusion criteria are provided.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It explains core functionality (search, retrieve, filter) but omits details like whether the operation is read-only, the response structure, pagination behavior beyond the schema, and any rate limiting. The description is adequate but leaves gaps in understanding what the tool does beyond the obvious.

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 three concise sentences, front-loaded with the main purpose, then specific use cases. Every sentence adds value—no redundancy or fluff. Highly efficient.

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 9 parameters and no output schema, the description covers the main filtering capabilities and common scenarios. It omits details about result format, error conditions, and pagination beyond schema descriptions. However, most use cases are covered, making it nearly complete for a search tool.

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 100%, so the parameters are well-documented in the schema. The description adds marginal value by contextualizing key parameters (e.g., 'hasBoxedWarning' as 'most serious safety warnings'), but largely restates schema descriptions. Baseline 3 is appropriate.

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 searches FDA drug labeling information, listing specific content types (prescribing info, indications, warnings, dosage, active ingredients) and usage patterns (by setId, filtering with hasBoxedWarning, requesting specific sections). It effectively distinguishes from sibling tools that cover devices, adverse events, NDC, etc.

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 explicit usage guidance: retrieving by setId, filtering by hasBoxedWarning, and limiting response via sections. While it doesn't explicitly state when not to use this tool or list alternatives, the context of sibling tools and the description's focus on drug labeling make the intended use clear. Could be improved by noting that adverse events should use search_drug_adverse_events.

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. It discloses that the tool returns 'product details, active ingredients, and packaging information,' which is adequate for a read-only search. However, it omits details on pagination behavior, rate limits, or empty result handling, though skip/limit parameters are in the schema.

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?

Two sentences efficiently state the core purpose and searchable fields, with no redundant or unnecessary information.

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 tool's main inputs and outputs, but given the lack of an output schema and the presence of many sibling tools, it could benefit from clarifying the specific use case (e.g., 'Use this for NDC-specific identification') or mentioning pagination. However, it is still reasonably complete for a search tool.

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 baseline is 3. The description reinforces the searchable fields but does not add new semantic meaning beyond what the parameter descriptions already convey.

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 specifies the tool's action ('Search the National Drug Code (NDC) Directory'), the resource ('drug product identification'), and the searchable fields (NDC, brand name, etc.), distinguishing it from sibling tools that target other FDA datasets.

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 lists searchable fields, implying use when identifying drugs by those attributes, but does not explicitly state when to avoid this tool or compare to siblings like search_drug_labels or search_drug_adverse_events.

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?

No annotations are provided, so the description should disclose behaviors like rate limits, authentication, or return format. It explains classification levels but omits pagination behavior, data source freshness, or any side effects.

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?

Two concise sentences. First sentence states purpose and lists filterable fields. Second sentence clarifies classification severity. No superfluous text.

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 searchable fields and classification meaning, but lacks information on the output format, pagination behavior, and any restrictions. Without annotations or an output schema, more context would improve completeness.

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 100% with each parameter described. The description adds meaning by explaining Class I severity, but this largely duplicates the schema's enum description. Overall minimal added value 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 searches drug recall and enforcement reports and lists the available filter fields (company, classification, status, state, date range). This distinguishes it from sibling tools focused on devices or adverse events.

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?

No guidance on when to use this tool versus alternatives like search_drug_adverse_events. The description does not specify prerequisites, exclusions, or optimal use cases.

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 burden. It discloses the tool returns application details, products, and submission history, but does not describe pagination behavior (skip/limit), rate limits, authentication needs, or what happens with no results. Basic transparency is present but incomplete.

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 two sentences (28 words), highly concise, front-loaded with the primary action, and includes specific search and return details. Every sentence adds value 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?

Given 6 parameters (none required) and no output schema, the description adequately covers purpose, search criteria, and return types. It does not detail default pagination but schema covers that. Overall, it is sufficiently complete for a search tool with well-documented parameters.

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 100% with all parameters described. The description adds context by listing searchable fields, but does not add significant new meaning beyond the schema. Baseline 3 is appropriate as schema already documents each parameter.

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 searches the Drugs@FDA database for approved drug applications, and lists specific search criteria (sponsor, application number, brand name, marketing status). It distinguishes itself from sibling tools like search_device_* or search_drug_adverse_events by focusing on approved drug applications.

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 for searching approved drug applications by various criteria, but lacks explicit guidance on when to use this tool versus alternatives (e.g., for adverse events use search_drug_adverse_events). No 'when not to use' or prerequisite information is provided.

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?

No annotations are provided, so the description must disclose behavioral traits. It mentions that results include shortage details, posting dates, and resolution information, but does not elaborate on pagination, rate limiting, or error handling. The description is functional but could be more transparent about behavior beyond basic output.

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 two sentences long with no wasted words. It front-loads the main action and immediately specifies the resource and search criteria. Highly concise and well-structured.

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 simplicity (4 parameters, none required, one enum) and complete schema descriptions, the description is mostly complete. It covers the main functionality and return types. Minor gap: the limit parameter's default (10) is in the schema but not in the description, but overall sufficient for agent decision-making.

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 100%, so the schema already documents all parameters. The description mentions searching by generic name or status, which aligns with parameters, but does not add new meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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 that it searches the FDA Drug Shortage Database for current and resolved shortages by generic drug name or status. It specifies the resource (database) and the verb (search), and distinguishes from sibling tools which are for other FDA data types (devices, labels, etc.).

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 explains how to search by generic drug name or status, providing clear use cases. However, it does not explicitly state when not to use this tool or name specific alternatives, though the sibling tools context implies different databases. This is adequate but not exemplary.

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?

No annotations provided, so description carries full burden. It mentions sorting and default inclusion of exclusivity data, but does not disclose pagination behavior (skip/limit), what happens if both drugName and applNo are provided, or that it is a read operation. These gaps limit transparency.

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?

Three concise sentences, front-loaded with core purpose, then usage details. No unnecessary words; every sentence adds value.

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, but description only vaguely says 'returns patents... with associated exclusivity data'. Lacks details on return fields or structure. Given complexity (unified view, optional parameter), more specifics on output would improve completeness.

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 100% (all parameters have descriptions), so baseline is 3. Description mentions drugName, applNo, and includePurpleBook but not skip, limit, or includeExclusivity. It adds minimal extra meaning beyond what schema already provides.

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 unified patent expiry and exclusivity view across Orange Book and optionally Purple Book, distinguishing it from sibling tools that cover only one book. It specifies search by drug name or application number, and mentions sorting by earliest expiry.

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?

Description provides explicit guidance on when to use the optional parameter includePurpleBook. However, it does not explicitly state when not to use this tool (e.g., for single-book queries) or mention alternative sibling tools.

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 full transparency burden. It discloses that data is downloaded from FDA bulk files and cached for 24 hours, indicating data freshness. It does not mention destructive actions, authentication, or rate limits, but overall it gives a good behavioral overview. No contradiction with annotations (none exist).

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 three sentences with no wasted words. It front-loads the core purpose, lists searchable parameters, mentions return values, and notes data caching. Every sentence adds value.

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 6 parameters, no required ones, and no output schema, the description covers usage, return content, and data source. It could include pagination behavior or error handling hints, but for a search tool it is reasonably complete.

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 covers all 6 parameters with descriptions, so schema_description_coverage is 100%. The description reiterates the main searchable fields but adds no additional detail beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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 searches the FDA Orange Book for approved drug products with therapeutic equivalence evaluations. It lists specific searchable fields (trade name, ingredient, applicant, application number, TE code) and mentions the return type (product details, patent counts, exclusivity counts). This distinguishes it from sibling tools like search_fda_purple_book (biological products) and others.

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 for finding drugs by various identifiers but does not explicitly state when not to use it or provide alternatives among the many sibling drug search tools. It lacks exclusion criteria, though the context is clear for Orange Book data. The description could guide agents away from using this for adverse events or recalls.

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?

No annotations are provided, so the description carries the full burden. It states the tool returns patent details but does not disclose behavioral traits such as rate limits, pagination behavior (beyond parameters), or whether the action is read-only. The absence of any behavioral context beyond 'returns' is a gap but not misleading.

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?

Two sentences, front-loaded with action and resource. Every sentence adds value: first states what it does, second details search parameters and returns. No fluff 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?

For a search tool with 5 optional parameters and no output schema, the description covers key inputs and typical outputs. It lacks mention of default limit or pagination behavior, but the schema partially compensates. Given sibling complexity (multiple FDA search tools), it sufficiently differentiates via patent-specific details.

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 100% with descriptions for all 5 parameters. The description only summarizes three of them (drugName, applNo, patentNo) without adding new meaning beyond the schema. For skip and limit, no additional context is provided. Baseline of 3 applies because schema does the heavy lifting.

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 verb 'Search', the resource 'FDA Orange Book patent data', and the specific search fields (drug name, application number, patent number). It also lists return details (expiry dates, flags, exclusivities), making it distinct from sibling tools like search_fda_orange_book (general) and search_fda_drug_patent_expiry (focused on expiry).

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 for searching Orange Book patents via various criteria, but does not explicitly guide when to choose this tool over alternatives like search_fda_orange_book or search_fda_drug_patent_expiry. The 'Find patents by...' phrasing suggests capability but lacks exclusionary context.

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. It states the tool returns product details, licensing status, and reference product information, implying a read-only operation. No destructive behavior is mentioned, which is appropriate for a search tool.

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 two sentences, front-loaded with the main purpose, and every word adds value. No unnecessary information.

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 8 parameters and no output schema, the description adequately explains the tool's function and return content. It omits details about pagination or output structure, but these are covered by the schema. Slightly more context on what the return data looks like would improve completeness.

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 100%, so baseline is 3. The description summarizes searchable fields but does not add new meaning beyond the schema descriptions. It groups parameters (e.g., 'license type (351(a)/351(k))') but does not provide additional context for skip, limit, or applicant.

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 searches the FDA Purple Book for licensed biological products, listing specific searchable fields (product name, applicant, BLA number, license type, biosimilar status, interchangeability). It distinguishes itself from siblings that search device or drug databases.

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 use for biologics, which differentiates it from drug and device sibling tools. However, it does not explicitly state when not to use or mention alternatives, such as using Orange Book for small molecules.

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