search_recordsFull-text search across 777k+ FDA 510(k) clearances, device recalls, and registered clinical trials. Returns ranked matches with links.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional: restrict to one record type | |
| query | Yes | Device name, manufacturer, sponsor, condition, or identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is read-only and non-destructive, so the description adds useful context beyond them: the 777k+ corpus size, full-text matching, and 'ranked matches with links.' It does not mention pagination or limits, but that is a minor gap at this complexity level.
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 tightly worded sentences front-load the search scope and then state the return behavior. There is no filler, no repetition of annotations, and every phrase 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?
For a two-parameter, fully documented, read-only tool, the description is nearly complete: it gives the corpus, the match semantics, and the result format ('ranked matches with links'). The only notable omission is explicit sibling-tool routing, but the agent has enough information to call this tool 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 coverage is 100%; both query and kind already have meaningful descriptions, and kind has an explicit enum. The tool description reinforces that this is full-text search but does not add parameter-level meaning beyond what the schema 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?
The description opens with a specific verb and resource: 'Full-text search across 777k+ FDA 510(k) clearances, device recalls, and registered clinical trials.' It also states the output shape. It does not explicitly contrast itself with sibling tools like search_recalls, so differentiation is left to inference.
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 corpus scope and full-text search behavior imply when this tool is useful, but there is no explicit when-to-use or exclusionary guidance. The agent is not told, for example, to prefer search_recalls when only recalls are needed or find_predicates for predicate lookups.
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.