search_recallsSearch FDA device recalls by product code, recalling firm, or free text. Returns recall details with links - use to vet a predicate candidate or monitor a market.
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | Recalling firm name (substring match) | |
| limit | No | Max results (default 15, max 40) | |
| query | No | Free text matched against the recall description | |
| product_code | No | Three-letter FDA product code, e.g. NBW |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show this is read-only and non-destructive. The description adds useful context by clarifying that results include recall details with links and that searches can be done by product code, firm, or free text. It does not describe pagination or behavior when no filters are supplied, but the annotations lower the bar.
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 filler. The main action and search dimensions come first, and the use case follows naturally.
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 simple search tool with no required parameters, the description is mostly complete: it covers search fields, return behavior, and use case. A small gap is that it does not state what happens when no search filters are provided, and 'recall details with links' is somewhat vague as an output description.
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 all four parameters are already documented in the input schema. The description's mention of product code, recalling firm, and free text largely mirrors the schema rather than adding new semantic detail.
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 operation, 'Search FDA device recalls', and lists the exact search dimensions: product code, recalling firm, and free text. It also communicates the intended use case, making it easy to tell apart from sibling tools like find_predicates and search_records.
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 use cases: vetting a predicate candidate or monitoring a market. It does not name sibling alternatives or give when-not-to-use guidance, so it stops short of full usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear primary purpose: AI device list, predicate candidates, monitoring feed, clearance detail, product code stats, recall search, and general full-text search. Minor overlap exists between find_predicates and product_code_stats (both product-code driven) and between search_recalls and search_records, but the descriptions distinguish specialized from general use.
Most tools follow a verb_noun pattern like find_predicates, get_changes, get_clearance, search_recalls, and search_records. Two names — ai_devices and product_code_stats — are noun phrases, creating a minor inconsistency, but the overall pattern remains readable and predictable.
Seven tools is well-scoped for a read-only FDA data server, covering lookup, search, statistics, monitoring, and specialized research use cases without unnecessary duplication. Each tool earns its place.
The set covers clearance details, recall search, product code statistics, change monitoring, predicate research, and the AI device list. There is no dedicated clinical trial tool, though search_records includes trials, and no device classification lookup, but these are workable gaps rather than dead ends.