openfda_adverse_eventsQuery the FDA Adverse Event Reporting System to find reported side effects for any drug by brand or generic name.
Query FDA Adverse Event Reporting System (FAERS) for drug side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-100). | |
| drug_name | Yes | Drug name (brand or generic, e.g., 'metformin', 'ozempic'). |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It identifies the data source (FAERS) but omits important context such as spontaneous reporting limitations, lack of causality, or any access constraints. For a data retrieval tool with no annotations, this is a significant gap.
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 a single, well-structured sentence that front-loads the core purpose. Every word earns its place with no 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?
The tool has low complexity (2 parameters, no nested objects) and an output schema, so return values need not be explained. The description is nearly complete for a simple query tool, though it could mention when to use this versus sibling FDA or DrugBank tools.
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 both parameters (drug_name and limit) are already documented in the schema. The description adds no parameter-specific detail beyond what the schema provides, which is the baseline case for high 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 states a clear verb ('Query') and a specific resource ('FDA Adverse Event Reporting System (FAERS) for drug side effects'). It distinguishes the tool from siblings such as openfda_drug_label and openfda_drug_enforcement by focusing on adverse events rather than labels or 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 provides no explicit when-to-use guidance, no prerequisites, and no alternatives. It implies the tool is for drug side effects, but an agent must infer that openfda_drug_label or openfda_drug_enforcement are different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.