An MCP server for DME billing, medical coding and healthcare market data — 20 tools in this schema spanning code lookup/validation, prior auth, claims, drugs, providers, trials and public health.
Medical coding — code_lookup, code_suggest (description → ranked codes), code_validate (with optional date-of-service context), code_crossref (ICD-10 ↔ CPT ↔ HCPCS), code_reimbursement (Medicare RVUs and payment)
Prior auth and claims — pa_predict (approval likelihood and factors), pa_status (track a PA), claims_validate (pre-submission error/mismatch check with fix suggestions)
Clinical text — ner_extract (codes, dates, medications with confidence) and compliance_audit (PHI pattern scan with severity score and remediation)
Drug data — drug_lookup (OpenFDA labels/adverse events), drug_interactions (FAERS co-report signals), drug_rxnorm (RxCUI normalization), drug_enrich (OpenFDA + AI summary)
Providers and market — provider_search (NPI registry), provider_enrich, provider_payments (Open Payments), market_analysis (specialty density and opportunity by state)
Clinical and public health — trials_search (ClinicalTrials.gov) and disease_surveillance (CDC NNDSS case counts)
The full published product also adds six free no-key tools (code_lookup_basic, reimbursement_basic, pa_required_check, denial_code_info, order_readiness_checklist, modifier_advisor), account/credit tools, batch variants, DMEPOS fee schedules, five billing prompts and three dataset resources.
Enables payment processing for purchasing credit packages to use the healthcare AI tools, allowing users to buy credits for medical billing services through Stripe payment integration.
MCP server for DME billing and medical coding. Connect Claude, Cursor, VS Code or any MCP client to 32 tools — code lookup across a database of 90K+ ICD-10-CM, CPT and HCPCS codes, DMEPOS fee schedules, Medicare prior-authorization and face-to-face list checks, denial-code guidance and pre-submission claim checks — plus five DME billing prompts and three dataset resources. Six tools work with no API key.
PHI-free by design: the tools take codes, modifiers, dates of service and de-identified text, never patient identifiers. Apart from drawing credits for paid calls, no tool changes anything except buy_credits, which opens a Stripe checkout session (nothing is charged until checkout is completed in the browser).
Claude (web or desktop) users: Settings → Connectors → Add custom connector → paste https://mymedi-ai.com/mcp-stream. The endpoint is OAuth-protected: Claude registers itself and asks you to sign in to MyMedi-AI once, and the first connector sign-in comes with free starter credits. There is no API key to copy.
Requires Node.js 20 or later.
claude mcp add mymedi-ai --env MCP_API_KEY=your-api-key -- npx -y @mymedi-ai/mcp-serverLeave out --env MCP_API_KEY=… to start with the six free tools. Other clients are under Client setup.
Registration is a POST request, not a web page:
curl -X POST https://mymedi-ai.com/bot-marketplace/register \
-H "Content-Type: application/json" \
-d '{"name": "my-agent"}'
# → { "apiKey": "...", "credits": ..., "quickStart": { ... } }Set the returned apiKey as MCP_API_KEY. (MYMEDI_API_KEY, the name the registration response prints, is accepted too; MCP_API_KEY wins when both are set.) A new key comes with free starter credits; the buy_credits tool adds more.
curl "https://mymedi-ai.com/agent/v1/demo?code=99213"Returns basic code metadata, rate-limited to 60 requests per hour per IP.
Related MCP server: LiveDataLink
Install the server without MCP_API_KEY and these work immediately (60 requests per hour per IP):
Tool | What it does |
| Is a HCPCS code on the CMS Required Prior Authorization List (42 CFR 414.234) on a date of service; phased-in items by state |
| DME denial code (CARC) explainer — meaning, common causes, fixes, appealability |
| Basic code metadata — code, type, description, category, active status |
| Medicare national PFS payment and DMEPOS fee-schedule ranges (rental/purchase) |
| Blank DMEPOS pre-delivery checklist — SWO elements, F2F/WOPD, prior authorization (42 CFR 410.38) |
| DMEPOS billing-modifier guidance — KX/GA/GY/GZ, RR/NU/UE, capped-rental months, laterality |
The other 26 tools need an API key (or the connector sign-in): 24 are paid per call, and account_status and buy_credits are free but need the key to identify the account.
Add to claude_desktop_config.json:
{
"mcpServers": {
"mymedi-ai": {
"command": "npx",
"args": ["-y", "@mymedi-ai/mcp-server"],
"env": {
"MCP_API_KEY": "your-api-key"
}
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"mymedi-ai": {
"command": "npx",
"args": ["-y", "@mymedi-ai/mcp-server"],
"env": { "MCP_API_KEY": "your-api-key" }
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"mymedi-ai": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@mymedi-ai/mcp-server"],
"env": { "MCP_API_KEY": "your-api-key" }
}
}
}claude mcp add mymedi-ai --env MCP_API_KEY=your-api-key -- npx -y @mymedi-ai/mcp-serverTool | Description | Price |
| Medicare DMEPOS prior-auth required check (42 CFR 414.234) | free |
| DME denial code (CARC) explainer | free |
| Basic code metadata lookup | free |
| Medicare national PFS payment + DMEPOS fee-schedule ranges | free |
| Blank DMEPOS pre-delivery checklist (SWO, F2F/WOPD, PA) | free |
| DMEPOS billing-modifier guidance (KX/GA/GY/GZ, RR/NU/UE, laterality) | free |
Tool | Description | Price |
| Credit balance, usage and recent transactions | free |
| Returns a Stripe checkout link to add credits; charges nothing by itself | free |
Tool | Description | Price |
| Look up an ICD-10, CPT or HCPCS code; labeled DMEPOS fee schedule, optional state | $0.001 |
| Up to 25 codes per call, per-item results; refunded when every code misses | $0.001/code |
| Code suggestions from a clinical description (term search, coverage ranking; refunded on no match) | $0.01 |
| Is a code valid and active, optionally on a date of service | $0.005 |
| Up to 25 codes per call, per-item results | $0.005/code |
| Related codes across ICD-10, CPT and HCPCS | $0.02 |
| Medicare PFS rates: RVUs and estimated payment | $0.01 |
| DMEPOS fee schedule — rental/purchase, rural/non-rural, by state | $0.01 |
Tool | Description | Price |
| Prior-auth approval rate from a real cohort of decided PAs, else the CMS list facts — never a made-up probability | $0.05 |
| Status of a PA tracked in your MyMedi-AI web workspace (does not query payers) | $0.02 |
| Map up to 100 HCPCS codes against the CMS PA and F2F/WOPD lists on a date of service, with documentation gates and denial-risk flags; pass a state for items phased in by state | $0.01/code |
| Pre-submission check of a claim's codes and date of service; does not assess medical necessity or prior authorization | $0.05 |
| Codes, dates and drug names already present in de-identified text (pattern extraction) | $0.02 |
| Pattern scan of a text payload for SSN, MRN and date-of-birth formats — screening, not a compliance audit | $0.25 |
Tool | Description | Price |
| OpenFDA drug label and adverse-event data | $0.01 |
| Drug-drug signals from FDA adverse-event co-reports (FAERS) | $0.03 |
| Normalize a drug name with NIH RxNorm (RxCUI, term type) | $0.02 |
| OpenFDA drug data plus an LLM-generated summary | $0.03 |
Tool | Description | Price |
| NPI registry (NPPES) search by name, specialty or location | $0.005 |
| NPPES record for an NPI plus a labelled LLM estimate of specialty demand, network gaps and referral categories | $0.05 |
| Industry payments to a physician (CMS Open Payments) | $0.02 |
| NPPES provider count for a specialty and state (a floor; one query returns at most 200) plus a labelled LLM estimate of demand and opportunities | $0.10 |
Tool | Description | Price |
| Clinical trials (ClinicalTrials.gov) | $0.03 |
| Notifiable-disease case counts (CDC NNDSS) | $0.02 |
Prompt | Arguments | What it does |
|
| Decodes the denial with |
|
| Assembles the blank pre-delivery paperwork checklist with |
|
| Checks codes and date of service with |
|
| Decodes the denial and outlines a redetermination letter with the documents to attach |
|
| Pulls |
Resource | URI | Contents |
PA Required List |
| CMS Required Prior Authorization List (42 CFR 414.234) with categories and nationwide-since dates |
F2F + WOPD List |
| CMS face-to-face / written-order-prior-to-delivery list (42 CFR 410.38(d)) plus the standard written order elements |
Platform overview |
| What MyMedi-AI is, the tool catalog, pricing and integration paths (read from the public site; a short summary if it cannot be reached) |
The per-tool price list is published as JSON at https://mymedi-ai.com/bot-marketplace/credits/pricing.
1 credit = $0.001. Paid tools cost from 1 credit (code_lookup) to 250 credits (compliance_audit) per call; code_lookup_batch, code_validate_batch and pa_exposure_report are priced per code. A failed call is refunded.
Each successful paid call's result includes a _billing field: { "creditsSpent": …, "creditsRemaining": …, "priceUSD": … }. (Over plain REST, without MCP, the same figures arrive as X-Credits-Spent / X-Credits-Remaining headers.)
account_status shows the balance and recent transactions. buy_credits returns a Stripe checkout link — $1 buys 1,000 credits, packages run from $1 to $500 — and the credits arrive once checkout is completed.
Variable | Description | Default |
| API key from registration; omit it to use only the free tools | — |
| Accepted alias of | — |
| API base URL |
|
| Shared-egress rate-limit token for hosted multi-user deployments (not needed for individual installs) | — |
|
| — |
| Address the HTTP mode listens on |
|
| Port the HTTP mode listens on |
|
| Bearer token clients must send to the HTTP mode; required when | — |
| Hostnames or addresses clients use to reach the HTTP mode (comma-separated); with | — |
| Browser origins allowed to call the HTTP mode (comma-separated, e.g. | none |
| Most open HTTP sessions |
|
| An HTTP session unused this long is closed |
|
--http)The same server can run over Streamable HTTP for clients that connect by URL:
MCP_API_KEY=your-api-key npx -y @mymedi-ai/mcp-server --http
# MCP HTTP server listening on http://127.0.0.1:8080/mcpEvery call through it spends the key in MCP_API_KEY, so the endpoint is guarded:
Loopback by default. It listens on 127.0.0.1 unless MCP_HOST says otherwise.
A token off loopback. With a non-loopback MCP_HOST (such as 0.0.0.0) the server refuses to start unless MCP_HTTP_TOKEN is set — at least 32 characters, for example openssl rand -hex 32. Clients then send Authorization: Bearer <token>; anything else gets 401. A token can be set on loopback too.
Host check. A request must name the server as localhost, 127.0.0.1, [::1], the MCP_HOST address, or a hostname or address in MCP_ALLOWED_HOSTS; any other Host gets 403. This stops DNS-rebinding pages. With MCP_HOST=0.0.0.0 the server has no address of its own to match, so list every address clients use — the LAN IP, the Docker host's IP, a DNS name — in MCP_ALLOWED_HOSTS.
Origin check. A request from a web page (it carries an Origin header) gets 403 unless that origin is in MCP_ALLOWED_ORIGINS, and only listed origins receive CORS headers. Desktop clients send no Origin and are unaffected.
Limits. Bodies over 1 MiB get 413, a body that is not JSON gets a JSON-RPC parse error, sessions are capped (MCP_MAX_SESSIONS) and closed after MCP_SESSION_IDLE_MS without use, and an unknown session id gets 404 so the client starts a new session.
Serving other machines:
MCP_HOST=0.0.0.0 MCP_HTTP_TOKEN="$(openssl rand -hex 32)" MCP_ALLOWED_HOSTS=mcp.example.com,192.168.1.20 \
MCP_API_KEY=your-api-key npx -y @mymedi-ai/mcp-server --httpPut TLS (a reverse proxy) in front of it when traffic leaves the machine: the token travels in a header.
Breaking for remote --http deployments only. Up to 1.7.5 the HTTP mode listened on every interface, served any caller without a token and sent Access-Control-Allow-Origin: *. From 1.7.6 it listens on 127.0.0.1; to serve other machines set MCP_HOST, MCP_HTTP_TOKEN (required off loopback) and MCP_ALLOWED_HOSTS with every hostname or address clients use (with MCP_HOST=0.0.0.0 that includes LAN and Docker-host IPs); browser-based clients also need MCP_ALLOWED_ORIGINS. An unknown session id now gets 404 instead of 400. stdio installs (Claude Desktop, Cursor, VS Code, Claude Code) are unaffected.
1.7.6 also requires Node.js 20 or later (Node 18 is past end of life, and the SDK's dependencies need 20). Also in 1.7.6: the server sends its instructions at initialize; scrub-claim takes an optional dateOfService and no longer asks about medical necessity; MYMEDI_API_KEY is accepted as an alias of MCP_API_KEY; and a paid call without a key explains how to register.
For programmatic use without MCP, install the SDK:
npm install @mymedi-ai/sdkimport { MyMediAI } from '@mymedi-ai/sdk';
const client = new MyMediAI({ apiKey: 'your-api-key' });
const result = await client.codeLookup('M79.3');ICD-10-CM and HCPCS Level II: CMS and CDC code sets
CPT®: from the CMS physician fee schedule (RVU) files. CPT® is a registered trademark of the American Medical Association (AMA); CPT codes and descriptions are AMA copyright.
Fee schedules and lists: CMS DMEPOS fee schedule, Medicare physician fee schedule (RVU), the Required Prior Authorization List and the F2F/WOPD list
Providers: CMS NPI registry (NPPES) and CMS Open Payments
Drugs: openFDA (labels, adverse events) and NIH RxNorm
Clinical and public health: ClinicalTrials.gov and CDC NNDSS
402 "payment_required" — without an API key, a paid tool answers with the registration request to send (see Get an API key); with a key, it means the credits ran out: call buy_credits. The six free tools never need a key.
"invalid_api_key" — the key in MCP_API_KEY (or MYMEDI_API_KEY) was not recognised: check it for a typo or a missing part and restart the server, or register a new key.
429 on free tools — free endpoints allow 60 requests per hour per IP. Wait, or use a key and the paid equivalents.
Connector won't connect — the hosted endpoint is https://mymedi-ai.com/mcp-stream (Streamable HTTP) and it is OAuth-protected. An unauthenticated request returns {"error":"unauthorized","error_description":"OAuth required"} — that is the endpoint working, not a fault, and a bare inspector --cli … --method tools/list shows it because it holds no token. To confirm the service is up, read the discovery document: curl -s https://mymedi-ai.com/.well-known/oauth-protected-resource names .../mcp-stream as the protected resource. Claude performs dynamic client registration and the sign-in itself.
--http answers 401, 403 or refuses to start — see HTTP mode: send the bearer token, add the hostname to MCP_ALLOWED_HOSTS or the web origin to MCP_ALLOWED_ORIGINS, and set MCP_HTTP_TOKEN before listening off loopback.
Code not found — lookups expect bare codes (E1390, 99213, M79.3). Denial codes accept CO-50, co50 or 50.
Data currency — reference data follows CMS release cycles; prior-authorization and F2F/WOPD answers carry the list version they were checked against.
Still stuck? Email support@mymedi-ai.com or open an issue at https://github.com/MyMedi-AI/mymedi-ai-mcp-server/issues.
API key registration: POST https://mymedi-ai.com/bot-marketplace/register (a request, not a page)
Hosted connector: https://mymedi-ai.com/mcp-stream
MIT
Pre-submission claims validation. Checks for errors, missing fields, code mismatches, and provides fix suggestions before you submit to the payer.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Claim data to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it checks and provides fix suggestions, implying non-destructive operation. But it lacks details on idempotency, side effects, or required permissions, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence front-loading the purpose and features, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nested objects and no output schema or annotations, the description provides adequate context for what the tool does and when to use it. However, return value format and error handling are not addressed, leaving some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds meaning by explaining that the claim object is validated for errors, missing fields, and code mismatches with fix suggestions, going beyond raw schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it validates claims before submission, checking errors, missing fields, code mismatches, and providing suggestions. This distinguishes it from sibling tools like code_validate (code-level) and compliance_audit (broader regulatory checks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'before you submit to the payer,' indicating when to use. However, it does not mention when not to use or directly reference alternatives, though the sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-reference a medical code across ICD-10, CPT, and HCPCS systems. Returns related codes grouped by system. Source: CodeReference DB (ICD-10/HCPCS: public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Medical code to cross-reference (e.g., "M79.3", "99213", "E0601") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the data source (public domain) but offers no details about response format, error handling, rate limits, or safety (e.g., read-only). This leaves the agent guessing about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a source line, front-loaded with the core action and immediately informative. Every part earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose and parameter context. It lacks output format details but provides enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'code', and the description provides helpful examples (e.g., 'M79.3', '99213'). However, it adds limited extra meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Cross-reference a medical code across ICD-10, CPT, and HCPCS systems' with a specific verb and resource, and it distinguishes from siblings like code_lookup and code_validate by emphasizing cross-system grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-system code comparison but lacks explicit guidance on when to use this tool versus siblings like code_lookup or code_validate. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up medical codes (ICD-10, CPT, HCPCS) by code string. Returns description, category, active status, and related codes.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Medical code to look up (e.g., "M79.3", "99213", "E0601") | |
| codeType | No | Code system (auto-detected if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides only basic behavioral context: it returns description, category, active status, and related codes. It does not disclose error handling, partial match behavior, or any read-only guarantee. The information is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and lists return fields. It is efficient with no wasted words. However, it could be slightly more structured (e.g., bullet points for return fields) but is still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description adequately covers the purpose, accepted codes, and return fields. It lacks details on edge cases or error handling but is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no additional parameter semantics beyond the schema; it mentions code string and code systems but those are already in the schema. No value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up medical codes by code string, lists the code systems (ICD-10, CPT, HCPCS), and specifies return fields (description, category, active status, related codes). This distinguishes it from siblings like code_suggest or code_validate, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for basic code lookups but does not explicitly state when to use it versus siblings like code_crossref or code_reimbursement. No exclusions or contextual triggers are mentioned, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Medicare reimbursement rates for a medical code. Returns RVU values and estimated payment amounts using CMS PFS conversion factor. Source: CMS PFS RVU 2026 (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Medical code (e.g., "99213", "M79.3") | |
| codeType | No | Code system (auto-detected if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the source (CMS PFS RVU 2026) and output (RVU values, estimated payment amounts). It implies a read-only operation ('Look up') but does not explicitly state idempotency or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, followed by source and output details. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters and no output schema. The description sufficiently explains the output and data source. It could mention error handling or precision, but it is generally complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented. The description adds no new parameter details beyond what the schema already provides (including auto-detection for codeType). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up Medicare reimbursement rates for a medical code, with specific verb 'look up' and resource 'Medicare reimbursement rates'. It distinguishes from sibling tools like code_lookup (general) and code_crossref (cross-referencing) by focusing on reimbursement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like code_lookup or code_suggest. While the purpose is clear, there is no guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-powered medical code suggestions from a clinical description. Returns ranked code suggestions with relevance scores.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Clinical description to find codes for (e.g., "chronic lower back pain") | |
| codeType | No | Limit to specific code system | |
| limit | No | Max suggestions to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'AI-powered' and 'ranked with relevance scores,' suggesting non-deterministic behavior, but lacks disclosure on determinism, authentication needs, rate limits, or fallback behavior. For a generative tool, more transparency about accuracy and latency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and output. Every word is purposeful; no fluff or unnecessary detail. It achieves high conciseness while covering the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required), no output schema, and no annotations, the description explains the input and output format ('ranked suggestions with relevance scores'). It could be more explicit about the output array structure or edge cases, but it is largely complete for a straightforward suggestion tool. The sibling context adds pressure to differentiate, which the description does effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it only rephrases 'clinical description' for 'description' and 'specific code system' for 'codeType.' The schema already provides clear descriptions for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get AI-powered medical code suggestions from a clinical description. Returns ranked code suggestions with relevance scores.' It specifies a specific verb ('get'), a resource ('medical code suggestions'), and the input source ('clinical description'). Among siblings like code_lookup and code_validate, this tool is distinguished by being AI-powered and returning ranked suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating code suggestions from free-text clinical descriptions, but it does not explicitly state when to use this tool versus alternatives like code_lookup (for direct code searches) or code_validate (for verifying codes). No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a medical code for correctness, active status, and context. Returns warnings and errors.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Medical code to validate | |
| codeType | No | ||
| context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It mentions 'returns warnings and errors' but does not elaborate on the nature of these, potential side effects, or requirements. Important aspects like how context affects validation or whether the tool modifies any state are omitted, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary detail. While it avoids fluff, it does not fully earn its place as it omits critical usage and parameter guidance. The structure is adequate but could be improved with additional clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters including a nested object, no output schema, no annotations), the description is insufficient. It fails to explain the validation criteria, how codeType and context influence results, or what the warnings/errors entail. An agent would lack critical information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'code' has a description). The tool description adds no parameter information at all. For a low-coverage schema, the description must compensate, but it fails to explain 'codeType' or 'context', leaving their semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as validating a medical code, specifying three aspects (correctness, active status, context) and the output (warnings and errors). This distinctly differentiates it from sibling tools like code_lookup or code_crossref, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives, such as code_lookup or code_suggest. No prerequisites, exclusions, or context for optimal use are provided, making it difficult for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HIPAA compliance audit. Scans data for PHI exposure (SSN, MRN, DOB patterns), returns findings with severity, score (0-100), and remediation recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data to audit for compliance issues | |
| auditType | No | Type of audit (default: general) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It indicates a read-only scanning operation (no mention of side effects) and specifies returned data (findings, severity, score, recommendations). Could explicitly state it is non-destructive, but current text is sufficiently clear for a read-only audit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with the key qualifier 'HIPAA'. Every word adds meaning, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, input parameters (partially via schema context), and output format. No output schema exists, but the return values are described. It lacks details on default auditType, but the schema covers that. Adequate for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds value by elaborating on the 'data' parameter (emphasizing PHI patterns like SSN, MRN, DOB) and mentioning output details, which supplement the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('scans'), resource ('data for PHI exposure'), and provides specific outputs (severity, score, recommendations). It distinguishes from siblings like claims_validate and code_validate by focusing on HIPAA compliance auditing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for HIPAA compliance audits but does not explicitly state when to use this tool versus alternatives (e.g., claims_validate for claim validation). No exclusions or alternate tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up disease surveillance data including case counts and trends by condition and geography. Source: CDC National Notifiable Diseases Surveillance System (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Disease or condition name (e.g., "Hepatitis A", "Salmonellosis") | |
| code | No | ICD-10 code (auto-mapped to condition name) | |
| state | No | 2-letter state code to filter by geography |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the data source (CDC public domain) which is helpful, but does not disclose any behavioral traits like rate limits, data freshness, or behavior on missing results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words. The first sentence states the main purpose, the second provides the source. Well structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should give some idea of return values. It mentions case counts and trends but lacks detail on format or structure. For a simple lookup, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for condition, code, and state. The description adds that the tool returns case counts and trends, but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up disease surveillance data (case counts, trends) by condition and geography. It distinguishes from siblings like code_lookup or drug_lookup by specifying public health data from CDC. However, the verb 'Look up' is somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for epidemiological data but does not explicitly state when it should be chosen over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drug information enrichment via OpenFDA. Returns drug details, indications, interactions, and AI analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| drugName | Yes | Drug name (brand or generic, min 2 chars) | |
| searchField | No | Search by brand or generic name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions data source (OpenFDA) and output types but lacks details on authentication, rate limits, or behavioral side effects. The tool likely performs multiple API calls, but this is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the purpose ('drug information enrichment via OpenFDA') and lists outputs. Efficient and to the point, though a more structured format could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description only lists categories (details, indications, interactions, AI analysis) without describing structure or format. For a tool that returns complex data, more detail on the response is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add extra meaning beyond the schema's explanation of drugName and searchField, but this is adequate since the schema is self-contained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enriches drug information via OpenFDA and lists outputs (details, indications, interactions, AI analysis). It differentiates from siblings like drug_lookup or drug_interactions by combining multiple aspects. However, the verb 'enrich' is slightly vague without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like drug_lookup or drug_interactions. The description implies comprehensiveness but does not state scenarios where enrichment is preferred over basic lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check drug-drug interaction signals from FDA adverse event co-reports. Returns co-reported reactions and signal strength. Source: OpenFDA FAERS (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| drugs | Yes | Array of 2-5 drug names to check for interactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. While it mentions the data source (OpenFDA FAERS, public domain), it does not discuss rate limits, data staleness, scope (adverse event co-reports vs. clinical interactions), or whether the tool is read-only. This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the core action and provide essential context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no output schema), the description is adequate but incomplete. It lacks details on the output format, any error handling, or usage limitations. While it covers the basic purpose, agents may need additional information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the 'drugs' parameter (array of 2-5 drug names). The description adds general context about the data source but does not enhance understanding of the parameter beyond what the schema offers. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking drug-drug interaction signals from FDA adverse event co-reports. It specifies the output (co-reported reactions and signal strength) and distinguishes itself from sibling tools like drug_lookup or drug_enrich by focusing on interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any limitations or prerequisites. The description only states what it does, leaving the agent without context for selecting it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up drug information including label data, adverse events, and related diagnosis codes. Source: OpenFDA (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| drugName | Yes | Drug name (brand, generic, or substance — min 2 chars) | |
| searchField | No | Search field (default: brand_name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions the source and data categories but omits rate limits, data freshness, read-only nature, or error behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then source. No unnecessary words. Efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a lookup tool with two well-documented parameters and no output schema, but lacks context on limitations, authentication, or what happens on missing data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the input schema already provides (e.g., min chars, default search field).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides drug information including label data, adverse events, and diagnosis codes. It distinguishes the general lookup function from more specific sibling tools like drug_interactions, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like drug_enrich or drug_rxnorm. No exclusions or prerequisites are mentioned, only the data source (OpenFDA).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a drug in NIH RxNorm for normalized terminology (RxCUI) and optionally check clinical drug-drug interactions with severity ratings. Source: NIH RxNorm (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| drugName | Yes | Drug name to look up (min 2 chars) | |
| checkInteractions | No | Other drug names to check for clinical interactions against the primary drug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns RxCUI and optionally checks interactions with severity ratings, and cites the public domain source. No destructive behavior or auth needs are mentioned, but this is acceptable for a read-only lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the primary purpose, the second adds an optional feature and source. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the key return value (RxCUI) and interaction output (severity ratings). It lacks details on output format or a usage example, but is sufficient for an agent to understand the tool's capability given the rich sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions. The description adds value by mentioning that interaction checks include 'severity ratings', which is not in the schema. This provides meaningful context beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up' and resource 'drug in NIH RxNorm', and mentions the optional interaction check. It distinguishes from siblings like drug_lookup and drug_interactions by combining both functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for normalized terminology and interaction checks, but does not explicitly state when to use this tool vs alternatives among the many sibling tools. No exclusion criteria or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Healthcare specialty market analysis for a specific state. Returns provider density, competition metrics, and market opportunity data.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter state code (e.g., "TX", "CA") | |
| specialty | Yes | Medical specialty (e.g., "cardiology", "orthopedics") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It only lists return data types but does not specify if the tool is read-only, any side effects, data freshness, or authorization requirements. This is insufficient for an agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and includes the key return items. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required params and no output schema, the description provides adequate high-level context but lacks detail on return format, data sources, or limits. It could briefly note if results are aggregated or raw.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (state code and specialty). The description adds no new insight beyond restating 'for a specific state', so it meets but does not exceed the baseline expected given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs healthcare specialty market analysis for a specific state, returning provider density, competition metrics, and market opportunity data. This verb+resource combination distinguishes it from sibling tools like provider_enrich or provider_search which focus on individual providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like provider_enrich or claims_validate. It does not mention any when-not-to-use scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract medical named entities from clinical text. Identifies ICD-10 codes, CPT codes, dates, medications, and 12 entity types with confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Clinical text to extract entities from | |
| entityTypes | No | Filter to specific entity types |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions output includes confidence scores, but omits crucial details: whether the tool is read-only, if it requires specific authentication, or any side effects. The agent cannot assess safety or side effects from this description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The verb+resource pattern is front-loaded. Every sentence adds unique information: first sentence states action and domain, second sentence lists notable outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially compensates by mentioning confidence scores but does not detail the structure of extracted entities (e.g., format, nesting, or error scenarios). It is adequate for a simple extraction tool but leaves some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining what the extraction produces (specific entity types and confidence scores), which clarifies the purpose of the 'entityTypes' filter parameter. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract' and the resource 'medical named entities from clinical text'. It lists specific entity types (ICD-10, CPT, dates, medications, and 12 entity types) with confidence scores, distinguishing it from sibling tools like code_lookup or drug_lookup which are lookups rather than extractions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not state when not to use it or provide references to sibling tools. The context is implied by the extraction focus, but no proactive help for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict prior authorization approval probability for a procedure. Returns approval likelihood (0-1), confidence level, estimated processing days, and contributing factors.
| Name | Required | Description | Default |
|---|---|---|---|
| procedureCode | Yes | CPT/HCPCS procedure code | |
| diagnosisCodes | No | Supporting ICD-10 diagnosis codes | |
| payerId | No | Insurance payer ID | |
| patientAge | No | Patient age in years | |
| patientGender | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers return values (likelihood, confidence, days, factors) but does not mention side effects, auth needs, or rate limits. Adequate for a read-like prediction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently deliver purpose and returns with no redundancy. Front-loaded with action verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key return elements but lacks caveats (e.g., model limitations, data recency). Adequate for a straightforward prediction tool given schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters described). The description adds no parameter-level details beyond schema, so meets baseline without improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Predict' and identifies the resource 'prior authorization approval probability', clearly distinguishing from sibling tools like pa_status (status check) or claims_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for predicting approval probability, but no explicit guidance on when to use vs alternatives (e.g., pa_status) or prerequisites like procedure code presence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a prior authorization request. Returns current status, dates, and expiration info.
| Name | Required | Description | Default |
|---|---|---|---|
| authorizationId | No | Prior authorization ID | |
| trackingNumber | No | Tracking number (alternative to authorizationId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'returns current status, dates, and expiration info,' which implies a safe, read-only operation. However, it does not mention any authentication requirements, rate limits, or data freshness, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, efficiently conveying the purpose and return details. It is front-loaded and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains return values (status, dates, expiration). However, it does not specify that at least one of the two optional parameters is required or describe error handling. For a simple lookup, it is minimally sufficient but lacks full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The description adds that it returns status, dates, and expiration info, but does not add new meaning beyond what the schema provides for the parameters. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a prior authorization request and specifies the return values (status, dates, expiration info). It distinguishes itself from sibling tools like claims_validate by focusing specifically on prior authorization status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives. The purpose is implied by the name and description, but no exclusion criteria or context for selection among sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-enriched provider intelligence from NPI number. Returns practice details, specialties, affiliations, and market context.
| Name | Required | Description | Default |
|---|---|---|---|
| npi | Yes | 10-digit NPI number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, authentication, rate limits, or whether results are cached. 'AI-enriched' implies processing but no further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load core purpose. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, description lists key return categories (practice details, specialties, etc.). For a single-parameter tool, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Description adds no semantic depth beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it takes an NPI number and returns enriched provider data (practice details, specialties, affiliations, market context). Distinct from sibling tools like provider_search and provider_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as provider_search. Does not specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up pharmaceutical and device company payments to a physician (Sunshine Act data). Returns total payments, breakdown by type, and top paying companies. Source: CMS Open Payments (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| npi | Yes | 10-digit NPI number of the physician |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially compensates by stating it is a lookup (read-only) and describing the output. However, it does not mention potential behavioral aspects such as rate limits, data year, or data refresh frequency. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information, and front-loads the core purpose. It efficiently conveys essential information without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key aspects: what the tool does, what it returns, and the data source. Given there is no output schema and no annotations, it provides a reasonable level of completeness for a simple lookup tool. However, it could be more complete by mentioning data year or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'npi' is already well-described in the schema as a 10-digit NPI number. The description adds no extra meaning beyond the schema, so it meets the baseline for full schema coverage but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: looking up payments to a physician from pharmaceutical and device companies. It specifies the data source (Sunshine Act, CMS Open Payments) and what it returns (total payments, breakdown by type, top paying companies). This distinctively differentiates it from sibling tools like provider_enrich or provider_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving payment data but does not provide explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. The context of being public domain is helpful, but without stating when not to use this tool, the agent may lack decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the NPI provider directory. Find healthcare providers by name, specialty, or location.
| Name | Required | Description | Default |
|---|---|---|---|
| firstName | No | ||
| lastName | No | ||
| organizationName | No | ||
| taxonomy | No | Provider taxonomy/specialty code | |
| city | No | ||
| state | No | 2-letter state code | |
| limit | No | Max results (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description merely says 'search' without disclosing read-only nature, pagination, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words; front-loaded key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description lacks detail on combining parameters, defaults, or output format, making it incomplete for a 7-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, and the description adds general categories but does not detail each parameter beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the NPI provider directory by name, specialty, or location, distinguishing it from sibling tools like provider_enrich.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Context is implied but no alternative or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active clinical trials by condition, ICD-10 code, or intervention. Returns trial details including NCT ID, phase, enrollment, and eligibility. Source: ClinicalTrials.gov (public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Medical condition to search for | |
| code | No | ICD-10 code (auto-mapped to condition) | |
| intervention | No | Drug or intervention name | |
| status | No | Trial status filter (default: RECRUITING) | |
| limit | No | Max results (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source and some return fields, which is helpful, but does not explicitly state that the tool is read-only, lacks rate limit or pagination info, and does not describe error handling or data freshness. The description is adequate but leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded key purpose and return fields, no extraneous text. Every word earns its place. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential: search criteria, return fields (NCT ID, phase, enrollment, eligibility), and data source. It is complete enough for an AI agent to understand the tool's basic function. However, it omits details like default status filter (RECRUITING) and limit behavior, which are only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that 'code' is auto-mapped to condition, which is not in the schema. However, it does not further elaborate on parameter dependencies or constraints beyond what the schema already provides. Overall, the description contributes minor additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Search active clinical trials by condition, ICD-10 code, or intervention.' It clearly identifies the tool's function and distinguishes it from siblings that handle claims, codes, drugs, etc. No other sibling tool targets clinical trials, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like drug_lookup or code_lookup. It states the data source (ClinicalTrials.gov) but does not specify contexts where this tool is preferred or when other tools should be used. This lack of comparative guidance hinders tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.1code_crossrefcode_reimbursementdisease_surveillancedrug_interactionsdrug_lookupdrug_rxnormprovider_paymentstrials_searchclaims_validatecode_lookupcode_suggestcode_validatecompliance_auditdrug_enrichmarket_analysisner_extractpa_predictpa_statusprovider_enrichprovider_searchScored across 20 tools
Most tools are clearly distinct by their targeted resource and action (e.g., claims_validate vs. code_lookup), but the multiple drug tools (drug_lookup, drug_enrich, drug_rxnorm) have overlapping purposes that could cause confusion despite descriptive names.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., claims_validate, code_lookup, provider_search), making the naming predictable and easy to parse.
With 20 tools, the set is slightly larger than the typical well-scoped range, but the breadth of healthcare domains (claims, codes, drugs, providers, compliance, trials) justifies the count; no tool feels superfluous.
The tool surface covers a wide range of medical workflows (code management, drug interactions, provider intelligence, compliance, etc.). Minor gaps like claim submission or patient data management exist, but core informational and validation tasks are well covered.
270 pay-per-call AI tools for agents, paid via x402 (USDC on Base). No signup, no API keys.
10 pay-per-call tools for AI agents: QR, screenshots, DNS, OCR, PDF, email & more. USDC on Base.
40+ Lightning-paid AI tools for agents: calls, SMS, fax, voice, translation. No signup, no keys.
70+ pay-per-call tools for AI agents: web search, email verify, KYC, stocks, crypto, news, data
