MCP server
Connect Claude, Cursor or any MCP client to Exclia: screening, coverage and monitoring as agent tools.
Exclia runs a remote Model Context Protocol (MCP) server, so an AI assistant or agent can screen names, read coverage and manage monitoring through the same /v1 API your code uses. There is nothing to install: point an MCP client at the endpoint and give it an API key.
https://api.exclia.com/mcpHow it works
- Transport: Streamable HTTP, stateless. Clients send JSON-RPC over
POST; there are no sessions to keep alive. - Authentication: the same API key as
/v1, sent asAuthorization: Bearer <key>, or OAuth sign-in for clients that cannot send a header (claude.ai connectors). A missing or revoked credential is refused before the client can even list tools. See Authentication. - Same rules as the API: every tool is a call to
/v1with your key, so rate limits, monthly allowances, billing status and metering apply exactly as they do to direct calls. A refusal (for example402 api_allowance_reached) comes back as a tool error with the API's own error body, which the assistant can read and explain. - Same results as the API: a result is
clearorpotential_matchwith per-field evidence and the source list version. A potential match is never a finding about the person; its label is "potential match — verification required", and the server's instructions tell the assistant so.
Tools
| Tool | Calls | What it does |
|---|---|---|
screen_person | POST /v1/screen | Screens one person. Pass the whole name in name; add dateOfBirth, npi and state when known. Metered. |
screen_organization | POST /v1/screen | Screens one practice, agency or vendor by legalName, with npi and state when known. Metered. |
batch_screen | POST /v1/batch | Queues many subjects and returns a jobId. Metered per item. |
get_batch_job | GET /v1/batch/{jobId} | Reads a batch job's state and, once complete, its results. |
monitor_entity | PUT /v1/monitor | Enrolls a person or organization in continuous monitoring and returns its id. |
stop_monitoring | DELETE /v1/monitor/{id} | Removes one entity from monitoring. |
list_coverage | GET /v1/lists | Lists every source list screened, with its live status and last refresh. |
get_usage | GET /v1/usage | Reads this period's screening and API usage. |
Read-only tools are annotated readOnlyHint, and stop_monitoring is annotated destructive, so clients that ask before acting will ask before removing a record.
Connect a client
Create a key in the app under API keys first, then store it as EXCLIA_API_KEY.
Claude (claude.ai, Claude Desktop and mobile connectors)
Add a custom connector with the URL https://api.exclia.com/mcp and leave the OAuth fields empty. Claude sends you to Exclia to sign in; the connector then acts for the one organization where you are an owner or admin, with the same allowances as an API key. If you administer more than one organization, use an API key from another client instead.
Claude Code
claude mcp add --transport http exclia https://api.exclia.com/mcp \
--header "Authorization: Bearer $EXCLIA_API_KEY"Cursor (~/.cursor/mcp.json)
{
"mcpServers": {
"exclia": {
"url": "https://api.exclia.com/mcp",
"headers": { "Authorization": "Bearer YOUR_EXCLIA_API_KEY" }
}
}
}VS Code (.vscode/mcp.json)
{
"servers": {
"exclia": {
"type": "http",
"url": "https://api.exclia.com/mcp",
"headers": { "Authorization": "Bearer ${input:excliaKey}" }
}
},
"inputs": [
{ "id": "excliaKey", "type": "promptString", "description": "Exclia API key", "password": true }
]
}Claude Desktop and other stdio-only clients can reach a remote server through the mcp-remote bridge:
{
"mcpServers": {
"exclia": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://api.exclia.com/mcp",
"--header",
"Authorization: Bearer ${EXCLIA_API_KEY}"
],
"env": { "EXCLIA_API_KEY": "YOUR_EXCLIA_API_KEY" }
}
}
}Try it with curl
curl https://api.exclia.com/mcp \
-H "Authorization: Bearer $EXCLIA_API_KEY" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Good practice for agents
- Keep a person in the loop. An assistant can find and summarize a potential match; deciding what it means belongs to your organization, after confirming identity with the publishing agency.
- Give it identifiers. A name alone matches namesakes. Date of birth, NPI and state are what separate them, so prompt the agent to pass them.
- Watch the meter. Every screen counts against your plan. Ask the agent to call
get_usagebefore a large job, and to usebatch_screenrather than hundreds of single calls. - Use a dedicated key. Give each agent its own key so you can rotate or revoke it without touching your production integration.
