FedWatch — Federal Funding & Lien Watcher

healthcare_search

Search FDA/CMS healthcare sources. openfda_drug_recalls (default): FDA drug enforcement/recall reports — keyword matches product description or recalling firm. openfda_device_510k: FDA 510(k) clearances — keyword matches device name or applicant. npi_registry: NPPES NPI registry — keyword is an organization-name prefix (city/state refine; an exact NPI goes in the apn field); phone numbers and authorized-official contacts are never returned. FDA warning letters have no openFDA endpoint (separate planned entry); CMS Open Payments is archived 2015–2022 and blocked as a live source — see fedwatch_sources.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "healthcare_search"
  }
}

Input Schema

Name	Required	Description
`apn`	No	NPI only: exact 10-digit NPI number
`city`	No	NPI only: practice city
`limit`	No	Maximum returned records (tier-capped)
`state`	No	NPI only: practice state (2-letter)
`status`	No	Recalls only: exact FDA status, e.g. 'Ongoing'
`keyword`	No	Keyword: product/firm (recalls), device/applicant (510k), organization name prefix (NPI)
`source_id`	No	Source id: openfda_drug_recalls (default), openfda_device_510k, or npi_registry

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A3.8/5.0

Behavior2/5

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

While it lists constraints, it does not offer deep behavioral insight beyond the parameter descriptions. It mentions that 'phone numbers and authorized-official contacts are never returned' for the NPI registry, which is a specific constraint on the output. However, since there are no annotations, the description is heavily burdened with expected traits, and the lack of information on mutation, rate limits, or processing status lowers this score significantly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but highly functional. It groups related pieces of information (source-specific instructions) together, keeping the logic coherent without unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of combining multiple source types (drug recalls, device approvals, registry lookups), the description effectively communicates the necessary constraints and limitations for a comprehensive understanding before invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description adds critical semantic value by detailing exactly what a keyword matches for each source (e.g., 'product description or recalling firm' for drug recalls; 'organization-name prefix' for NPI registry) which is not fully clear from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose is to 'Search FDA/CMS healthcare sources.' It then lists specific sources and what they contain (drug recalls, 510k clearances, NPI registry data), clearly separating the functions of the available parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on parameter usage by specifying 'NPI only' constraints for the apn/city/state fields, and directs the agent to use 'fedwatch_sources' for issues outside of the currently supported endpoints (like FDA warning letters).

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

All FedWatch — Federal Funding & Lien Watcher tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?