AI Tools / Healthcare
Auditable clinical-trial evidence for AI agents.
Retrieve exact trial records, sites, eligibility text, linked publications, and version history as bounded, citation-ready evidence packets.
Access
Public beta. No model credentials are sent to OpenNash. Your MCP client supplies its own inference.
Connect
This is a remote MCP server, so it works with whatever assistant you already use — ChatGPT, Claude, Gemini, Cursor, or any other MCP-compatible client. There is nothing to install, no account, and no API key. You point your assistant at one URL and it gains the tools.
https://api.opennash.com/healthcare/mcpThe fast way: paste this to your assistant
Copy the message below into ChatGPT, Claude, Gemini, or your chatbot of choice. It contains everything the assistant needs — it will connect itself and tell you what it can do.
Please connect to the OpenNash Clinical Trial Evidence MCP server and then
tell me which tools it gave you.
Endpoint: https://api.opennash.com/healthcare/mcp
Transport: MCP streamable HTTP. No login, no API key.
If your setup uses a JSON config file, this is the entry:
{"mcpServers":{"opennash-health":{"type":"http","url":"https://api.opennash.com/healthcare/mcp"}}}
Once connected, use it whenever I ask about clinical trials, drug labels, or
biomedical identifiers and I need the exact public record rather than your own
recollection — real NCT numbers, real study sites, the eligibility text as
written, each with its source link and record version. Prefer
build_trial_evidence_packet for trial questions, and validate_identifier when I
need to confirm an NCT or PubMed ID actually exists. Always show me the
canonical source URL, and say plainly when a record could not be retrieved
rather than filling the gap. Do not use this for general health education, and
never present anything it returns as medical advice.
If your assistant cannot add connectors itself, it will say so — use the manual steps below, then paste the message again so it knows when to reach for the tools.
Adding it manually
Every client words this slightly differently, but the shape is the same: find where custom connectors or MCP servers are added, choose the remote or HTTP option, and paste the endpoint above.
- ChatGPT — open Settings, find Connectors, and add a custom connector pointing at the endpoint. On Business and Enterprise plans a workspace admin usually adds it once for everybody. This server publishes the
searchandfetchtools ChatGPT expects, so it also works as a deep-research source. - Claude — open Settings, find Connectors, and add a custom connector with the endpoint. Custom connectors are a paid-plan feature; once added to your account or workspace, the connector is available to Claude wherever you work with it.
- Claude Code — one command:
claude mcp add --transport http opennash-health https://api.opennash.com/healthcare/mcp - Gemini, Cursor, and other MCP clients — these read a JSON config file. Add the entry below, then restart the client.
{
"mcpServers": {
"opennash-health": {
"type": "http",
"url": "https://api.opennash.com/healthcare/mcp"
}
}
}
Live endpoint. Remote HTTP clients must support the MCP streamable HTTP transport and accept text/event-stream. Consumer chat apps generally need a paid tier before they will add custom connectors, and workplace accounts may need an administrator to approve it.
When it helps
An AI model answering from memory will produce trial numbers, sites, and eligibility text that look right and sometimes are not. This tool makes the assistant go and read the actual public record instead. In practice that means:
- Finding the right trials. Search by condition, drug or intervention, phase, recruiting status, and location — and get trials that genuinely match those filters.
- Pulling up one specific trial. Ask for an NCT number and get that exact study back. If it does not exist, you are told so rather than handed a similar-sounding one.
- Reading sites and eligibility as written. Where a study is actually running and who it will actually accept, quoted from the registry with the source link and the version of the record it came from.
- Connecting trials to their published papers. Which publications are linked to a study, with results papers ahead of protocols and background reading.
- Checking your citations and spotting changes. Confirm an NCT or PubMed ID resolves to a real record before you rely on it, and see what has changed in a trial record since you last looked.
One answer-ready operation
Ask the client to call build_trial_evidence_packet. The response starts with canonical NCT IDs, the most relevant registry and publication evidence, source URLs, record versions, short supporting excerpts, known omissions, and what the records do not establish. Large site lists, eligibility text, and raw registry metadata are capped instead of flooding the model context.
Useful requests
- “Find recruiting phase 2 colorectal-cancer trials in California. Return canonical NCT links, ten sites per trial, and the reported eligibility text.”
- “Build a trial evidence packet for NCT04267848. Put results publications before protocols and state what each source establishes.”
- “What changed in these trial records since we last retrieved them?”
- “Validate whether PMID 39824200 and NCT04267848 resolve to exact source records.”
Safety boundaries
Search text is sent to the selected public source. Durable run records redact user query text and upstream-echoed raw fields, but that is not permission to submit sensitive data.
Built for inspectable workflows
Results carry stable source identifiers, canonical URLs, retrieval timestamps, record versions, and explicit limitations. Source failure is reported separately from “no matching record.” Model prose is never treated as source evidence.
Building a regulated healthcare agent or evidence workflow? hello@opennash.com →