Skip to main content
Glama

Healthparse Healthcare Data Gateway

by io.healthparse
OverviewDiscussionsAdmin

prescribers_partDClassWhitespace_search

Find high-volume Medicare Part D prescribers of a therapeutic class who have NO reported CMS Open Payments — the greenfield 'reachable before a competitor' audience for a smaller or newer brand. Filter by drug_class (GLP-1|SGLT2|DPP-4|Statin), min_claims, state, specialty, and optionally nature_of_payment (whitespace within that payment category). Anti-join of by-drug prescribers to Open Payments recipients. Public CMS data; not a consumer report. [price: $0.1/call]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
stateNo2-letter prescriber state code(s), comma-separated
offsetNo
engagedNotrue → INVERT: high-volume class prescribers who ARE receiving Open Payments (reachable KOLs), with op_total_amount. Default false = whitespace (unpaid).
specialtyNoprescriber specialty substring, e.g. 'Endocrinology'
drug_classYestherapeutic class from partd_drug_class: 'GLP-1' | 'SGLT2' | 'DPP-4' | 'Statin'
min_claimsNominimum PY2024 class claims to count as high-volume (default 50)
nature_of_paymentNooptional: whitespace within a payment category, e.g. 'Consulting'; omit for no payments at all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / engaged
      Added value: +{
+  "description": "true → INVERT: high-volume class prescribers who ARE receiving Open Payments (reachable KOLs), with op_total_amount. Default false = whitespace (unpaid).",
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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 that the tool performs an 'anti-join of by-drug prescribers to Open Payments recipients', mentions the data source ('Public CMS data; not a consumer report'), and includes pricing. It does not discuss mutation or side effects, but the operation is a read-only search.

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

Conciseness5/5

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

The description is concise: two sentences and a note. It front-loads the core purpose, then explains the mechanism and data source. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers the tool's logic, data source, and optional parameters. It explains the anti-join and the 'whitespace' concept. For a search tool, it is reasonably complete, though it could mention return fields or pagination.

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

Parameters4/5

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

The description adds meaning beyond the schema by explaining the overall concept of 'whitespace' and the 'engaged' parameter for inverting results. With 75% schema coverage, the description compensates for the remaining parameters by contextualizing the anti-join logic, though it doesn't detail every parameter.

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

Purpose5/5

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

The description clearly states the verb 'Find' and the resource 'high-volume Medicare Part D prescribers' with the specific condition of having 'NO reported CMS Open Payments'. It further explains the use case as a 'greenfield reachable before a competitor' audience, effectively distinguishing it from sibling tools like 'prescribers_partD_search' or 'openPayments_recipients_search'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions the intended use case (finding prescribers without Open Payments for marketing outreach) and provides context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools, but the sibling list implies differentiation.

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

All Healthparse Healthcare Data Gateway toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources