MCP server
Read-only tools, prompt templates and resources over one endpoint, so an AI tool can look rates up itself.
MCP (Model Context Protocol) is the open standard that AI tools use to call live data sources themselves. Point Claude or Cursor at this server and the model looks rates up during the conversation instead of relying on what you paste in. Every tool is read-only: an AI tool can query our data but can never change anything here. The tool table below is read from the server, so it lists every live tool, including those added by feature modules.
- Server URLhttps://data.soro.health/mcp
- AuthYour sk_live_ API keys, sent as Authorization: Bearer on every request.
- PlansEvery plan sees the same tool list; the data inside each result depends on the key's plan, exactly as on /v1.
- LimitsMCP calls spend the same per-key, per-minute budget as /v1, so a client pointed at this server draws on the same allowance as your own code, and either one can use it up for the other. There are no X-RateLimit-* headers here. Instead, every tool result, including errors, carries rate (limit, remaining and reset) inside structuredContent. A call over the limit gets a JSON-RPC error that says how long to wait.
| Tool | What it does |
|---|---|
| search_codes | Browse the code table: hospital and rate counts per code, with low, median and high rates for keys on Market Analytics. |
| get_code | Hospital rows for one code, each with its market percentile and price band (very low to very high), plus the national benchmark. Returned 50 rows at a time, most expensive first. |
| search_rates | Provider-group rows for one code from the payers' own price files: payer, billing class and the group's NPIs, with the rate and TIN for keys on Market Analytics. |
| get_provider_profile | One NPI's profile, the same sections for every provider: NPPES registration, CMS enrollment, the payers' price files in and out of network, Medicare Part B volume and the sources checked. |
| search_providers | Find providers by name or NPI in NPPES. |
| get_fee_schedule | One provider group's book from the payers' price files, by NPI, page by page, or pivoted code by payer. |
| batch_rates | Many codes at many hospitals in one matrix, with a row for every pairing, including those not on file. A name given twice counts once, and anything past the limits is listed under dropped. |
| compare_rates | The market percentile spread for a code, or one hospital's position within it. Where the hospital prices the code as a percent of charges, it also carries the pctOfCharge inputs and their note (explained on the API page): these are filed inputs, and their product is an estimate, not a rate. |
| search_hospitals | The facility directory, filterable by state, name and kind. |
| get_hospital | One facility: profile, payer coverage, value score and contract detail. Slugs come from search_hospitals and end with the facility's CMS certification number (CCN); contract groups are returned 50 at a time. |
| list_payers | The payer directory with coverage counts. |
| get_mrf_health | Health rows from our tracker of hospital machine-readable files (MRFs): status, when we last checked, schema and freshness for each file. Filter by hospital name or by a facility slug, which is converted back to the name. Public metadata only, with no dollar figures. |
| get_usage | The key's access level, its per-minute limit and the requests it has left this minute. |
| draft_report | A cited research report (market, payer comparison, negotiation brief, diligence, Medicare relativity, competitor study, statewide transparency) drafted from live lookups with the key's access. Counts against the key's daily assistant allowance. |
Ready-made templates that a client lists in its slash menu (prompts/list, prompts/get). Each one names the tools that answer it, and arguments are inserted as plain text.
| Prompt | Arguments | What it drafts |
|---|---|---|
| market_report | state, city, line | A market report for one specialty in one place. |
| payer_comparison | codes, state | How the payers compare on a set of codes. |
| negotiation_brief | provider, codes, state | A negotiation brief for one provider or group. |
| hospital_comparison | hospitals, codes | Two to four hospitals side by side with a rate matrix. |
| medicare_relativity | codes, state | Commercial-to-Medicare ratio for a list of codes. |
Two documents an agent can read before it asks (resources/list, resources/read).
- soro://methodologyHow our data is built, what a negotiated rate means here, what each plan can see, and the glossary.
- soro://schemasEvery tool's input schema, the prompt templates and the report types.
claude mcp add --transport http soro-data https://data.soro.health/mcp \ --header "Authorization: Bearer sk_live_..."
# Codex reads the key from the environment rather than the file, # so put the key in your shell and name the variable here. export SORO_API_KEY=sk_live_... codex mcp add soro-data --url https://data.soro.health/mcp \ --bearer-token-env-var SORO_API_KEY # which writes this into ~/.codex/config.toml [mcp_servers.soro-data] url = "https://data.soro.health/mcp" bearer_token_env_var = "SORO_API_KEY"
# ~/.cursor/mcp.json
{
"mcpServers": {
"soro-data": {
"url": "https://data.soro.health/mcp",
"headers": { "Authorization": "Bearer sk_live_..." }
}
}
}
# .vscode/mcp.json
{
"servers": {
"soro-data": {
"type": "http",
"url": "https://data.soro.health/mcp",
"headers": { "Authorization": "Bearer sk_live_..." }
}
}
}
# claude_desktop_config.json, bridged through mcp-remote.
# Keep "Authorization:Bearer" unspaced; some clients mangle a
# spaced header value on the command line.
{
"mcpServers": {
"soro-data": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://data.soro.health/mcp",
"--header", "Authorization:Bearer ${SORO_API_KEY}"],
"env": { "SORO_API_KEY": "sk_live_..." }
}
}
}
Custom connectors on claude.ai in the browser take only a URL, and this server does not support OAuth yet, so add it there with your connector link from the top of this page, which carries the key in its address. Every client above takes the plain server URL: four of them send the key as a header, and Codex reads it from an environment variable you name, so the key never lands in the config file.
“What does DRG 470 go for across New Jersey hospitals, and which end of the market is Morristown Medical Center on?”
“Run CPT 30520 and DRG 470 against St Joseph's Syracuse and St Peter's Albany and tell me which pairings are actually on file.”
“Pull Chilton Medical Center's profile: which payers does it contract with, and how do its rates sit against the state average?”
“Find the CPT 99213 market median and name the hospitals pricing it above the 85th percentile.”
Give the code system with the number (CPT 99213, DRG 470), since the same digits can exist in more than one system. Name hospitals the way you know them; batch matching reports anything ambiguous instead of guessing.
Create your sk_live_ keys on the API page, which also has the endpoint reference for calling the same data over plain HTTP.