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

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses returned fields (classification with the Class I severity meaning, reason, status) and that results are 'recent' enforcement reports, but it says nothing about pagination, result ordering, rate limits, or matching strictness.

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?

A single compact sentence, front-loaded with the resource and followed by the discriminating context (recency, classification severity, returned fields). No filler.

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?

An output schema exists, so return-value detail need not be repeated, but with no annotations and 0% schema coverage the description leaves real gaps: what 'recent' means, how 'limit' behaves, and whether results are sorted by date. Adequate to call, not 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?

Schema coverage is 0%, so the description has to compensate. It clarifies that 'drug' is used as a name-matching filter and that records are recent, but it leaves 'limit' (default 5) and the exact-match vs substring semantics of 'drug' entirely undocumented.

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?

States a specific resource (FDA drug recall enforcement reports) and scope (recent, matching a drug name), which clearly separates it from siblings like get_adverse_events and search_drug_labels. The retrieval verb is only implicit ('matching'), so it stops just short of a fully explicit verb+resource statement.

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?

Usage is implied by the drug-name matching scope, but there is no explicit when-to-use guidance, no mention of when to prefer get_adverse_events or search_drug_labels instead, and no note on result-volume limits or recency window. An agent can infer the use case but gets no routing rules.

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 disclosure burden. It usefully reveals the data source (FAERS) and that the output is raw report counts rather than causality or disproportionality, but it omits caveats that matter for FAERS data (spontaneous/voluntary reports), behavior on unknown drug names, and whether results are sorted or truncated.

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?

A single front-loaded sentence carries the core purpose, data source, and output content, with the optional filter appended. The trailing fragment is slightly clipped but costs almost nothing in length.

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?

An output schema exists, so return values need not be explained, and the tool has only three simple parameters. What remains missing — FAERS data caveats, the meaning of 'limit', and error behavior for unmatched drugs — is modest given the tool's simplicity and the presence of an output schema.

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 supply parameter meaning. It covers 'drug' implicitly and 'serious_only' explicitly ('only serious reports'), but says nothing about 'limit' — an agent cannot tell whether it caps the number of reaction terms returned or the number of reports per term, which is a meaningful ambiguity.

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 resource (most frequently reported adverse reactions), the underlying data source (FAERS), and the return content (report counts), which is far more informative than the tool name alone. It does not explicitly contrast itself with adjacent siblings such as signal_check or drug_recalls, so sibling differentiation is only partial.

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?

There is no statement of when to use this versus signal_check (disproportionality signals) or drug_recalls, both of which an agent could plausibly confuse with adverse-event frequency data. The only usage hint is the trailing 'optionally only serious reports', which describes a parameter rather than a selection rule.

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 supplied, so the description carries the full disclosure burden. It makes clear this is a read of a single trial's full record and scopes what is included (summary, eligibility, outcomes, enrollment, sponsor, status), but says nothing about behavior on an unknown/invalid NCT id, rate limits, or whether records are cached.

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?

A single front-loaded sentence that puts the verb and identifier first, then the payload. The field list is slightly redundant with the output schema but aids quick scanning without bloat.

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?

An output schema exists, so return values need not be spelled out, and the description still signals scope. For a one-parameter read tool this is nearly complete; only error/not-found behavior is unaddressed.

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?

There is one parameter with 0% schema description coverage, so the description must compensate. 'By NCT id' does tell the agent the identifier type (an NCT registry id, not a title or numeric key), but it gives no format example (e.g., NCT01234567) or normalization/case guidance.

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?

States a specific verb and resource ('Full details of one clinical trial by NCT id') and enumerates the content returned, which makes it clearly distinct from the sibling search_trials in intent (single-record retrieval vs. discovery). It never names the sibling or explains the relationship, so the differentiation is implied rather than stated.

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 'by NCT id' implies the precondition that the caller already has a known identifier, which suggests the search_trials-then-get_trial workflow. However, there is no explicit when-to-use, when-not-to-use, or named alternative, so an agent must infer the routing.

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 load, and it does add real value by disclosing the returned sections, that text is trimmed, and that a DailyMed link is included. It does not state read-only nature explicitly, truncation limits, or how many matches come back by default despite the limit param.

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 what is searched and followed by what comes back. No filler or redundant restatement of the tool name.

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?

An output schema exists, so return values need no deep explanation, yet the description still summarizes the returned sections usefully. Minor gap: the meaning of `limit` and result ordering are left unstated.

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?

'By brand or generic name' maps onto the required `drug` parameter and clarifies an ambiguity the bare schema leaves open (0% description coverage). However, the `limit` parameter is never mentioned, so half of the parameter set is unexplained beyond the schema's bare type and 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?

States a specific verb and resource (search FDA drug labels / package inserts) and the search key (brand or generic name). The enumerated returned sections make it clearly distinct from siblings like drug_recalls or get_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?

Usage is implied by 'search ... by brand or generic name,' but there is no explicit statement of when to choose this over get_adverse_events, drug_recalls, or signal_check, and no noting of when not to use it. An agent must infer the routing itself.

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 of behavioral disclosure. It says the tool searches and returns fields, which implies a read operation, but it does not state read-only behavior, authentication needs, rate limits, or pagination/default-limit behavior. For a search tool with zero annotations, these gaps matter.

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 short sentences front-load the main capability, then list filters, then summarize returned fields. Every sentence contributes useful information, and there is no filler or repetition.

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?

An output schema exists, so returned fields need not be fully explained, and the description still names key return fields. But with six optional parameters and no annotations, it should ideally cover `limit`/pagination and clarify search-combination semantics. It is adequate for basic invocation but incomplete for fully informed 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?

Schema coverage is 0%, so the description must compensate, and it does add meaning for condition, intervention, sponsor, status, and phase, including status and phase examples. However, it omits the `limit` parameter entirely and does not clarify whether condition, intervention, and sponsor are combined with AND or OR logic.

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 and resource: search ClinicalTrials.gov trials by condition, intervention and/or sponsor. It also names filters and returned fields, so the core purpose is clear. However, it does not explicitly distinguish this search tool from the sibling `get_trial`, leaving some sibling differentiation implicit.

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 the tool is for searching trials by condition, intervention, sponsor, status, or phase, but it gives no explicit when-to-use guidance. It also does not mention when to use `search_trials` instead of `get_trial` or other sibling tools, so an agent must infer routing.

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 and does disclose key behavior: it computes PRR, ROR, 95% confidence intervals, Yates chi-squared, and Evans signal criteria. It does not describe data recency, minimum case thresholds, or what happens when a drug-reaction pair has sparse or no reports, leaving some operational gaps.

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 efficiently packed sentences with no filler. The tool's purpose and analytical outputs are front-loaded, followed by the critical input-format constraint.

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 two-parameter statistical lookup tool with an output schema, the description provides enough context to invoke it correctly: FAERS source, required MedDRA vocabulary, and the returned signal metrics. It is slightly incomplete on drug name formatting and edge-case behavior, but the output schema covers return-value 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 description coverage is 0%, so the description must compensate for parameter meaning. It explains the reaction parameter well by requiring MedDRA preferred terms and giving 'PANCREATITIS' as an example, but it says nothing about drug name format or normalization, leaving one of the two required parameters under-specified.

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: 'Pharmacovigilance signal check for a drug-reaction pair in FAERS', and names the exact statistics produced (PRR, ROR, confidence intervals, Yates chi-squared, Evans criteria). This is clearly distinct from siblings such as search_drug_labels and get_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?

It gives clear context for use (FAERS disproportionality analysis) and specifies the necessary input vocabulary: 'Use MedDRA preferred terms, e.g. PANCREATITIS'. It does not explicitly state when not to use it or name alternatives, but no sibling tool performs signal detection, so the guidance is sufficient.

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