Arca Life Sciences

Search FDA, regulatory, and public health records

search_medical

Read-onlyIdempotent

Hybrid keyword + semantic search over Arca's mirrored public-source corpus: FDA drug labels, Drugs@FDA approvals, complete response letters, warning letters, Orange Book, Purple Book, NDC, drug shortages, device 510(k)/PMA/registrations, MAUDE adverse events, DailyMed, GUDID, postmarket requirements, import refusals, inspections, Form 483s, ClinicalTrials.gov studies, VAERS reports, CDC data, EU expert panel opinions, and BfArM/PMDA device vigilance. Read-only lookup of already-published records: it cannot file, submit, or report anything to FDA, VAERS, MedWatch, or any other agency, so do not call it for requests to file or submit a report. When the question names a record type (warning letters, labels, adverse event reports, trials, recalls), pass the matching sourceTypes rather than searching the whole corpus. Results carry recordId for fetch_source_record and a citable source URL.

Input Schema

Name	Required	Description
`query`	Yes	Medical, pharma, clinical, regulatory, device, or safety research query.
`numResults`	No	Results to return (1-25, default 10).
`sourceTypes`	No	Optional source lanes to focus the search (see list_datasets). Omit to search the whole corpus.
`publicSourceFilters`	No	Exact metadata filters for FDA enforcement, 510(k)/PMA device decisions, drug labels, FDA guidance, ClinicalTrials.gov studies, Health Canada drug records, EudraGMDP, BfArM/PMDA device notices, FDA complete response letters and EU MDR/IVDR expert-panel opinions. Device record date is the decision date, not receipt. Label record date is SPL effective date. Trial record date is first submission, postedDate is first posting; study milestones and lastUpdateDate are separate. Unknown or partial dates do not match ranges.

Output Schema

Name	Required	Description
`error`	No
`results`	Yes
`incomplete`	No
`returnedCount`	Yes
`continueInArca`	Yes	Link that opens this question in Arca's research chat on arca.inc, which runs a longer multi-step search and writes a fuller cited answer. Offer it to the user once, at the end of the answer.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real context: the corpus is a mirror of already-published records, no submission capability exists, and results carry recordId and a citable source URL. It does not mention result ranking, pagination, or latency, which keeps it short of a 5.

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

Conciseness3/5

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

The operative guidance is front-loaded, but the long comma-chained inventory of source databases is a catalogue dump that consumes most of the sentence without changing how an agent calls the tool. It is informative but bloated relative to the two or three rules that actually matter.

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?

An output schema exists, so return values need no explanation, and the description covers scope, safety boundaries, result handles, and source-lane selection. For a four-parameter search tool with fully documented schema, this is close to complete; only ranking/pagination expectations are unstated.

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

Parameters3/5

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

Schema coverage is 100% and the facets (dateField semantics, DINS/NDC preservation, decision codes) are documented in the schema itself. The description adds one useful piece of strategy—prefer sourceTypes over whole-corpus search—and points at list_datasets for the lane list, but adds nothing about numResults or the 50-value filter budget. Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and mechanism ("hybrid keyword + semantic search") over a concretely named corpus (FDA labels, MAUDE, 510(k)/PMA, ClinicalTrials.gov, VAERS, etc.), which lets an agent distinguish it from search_papers and fetch_source_record immediately.

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?

Gives an explicit when-not ("do not call it for requests to file or submit a report") and a positive routing rule ("when the question names a record type, pass the matching sourceTypes rather than searching the whole corpus"), plus names fetch_source_record as the consumer of returned recordIds.

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

All Arca Life Sciences 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?