Explains codes, insurance terms and math on a medical Explanation of Benefits or bill. Read-only.
Scored across 5 tools
Each tool has a distinct role: arithmetic validation, terminology explanation, procedural guidance, known-code lookup, or code discovery. The minor content overlap between the glossary and reading guide, and between code lookup and search, is clearly resolved by the usage descriptions.
All five tools use consistent lowercase snake_case with a clear verb followed by the object or domain. Singular and plural resource names appropriately reflect whether each call handles one item or multiple items.
Five tools are well matched to a focused EOB-decoding server, and each supports a distinct recurring task. The set avoids both unnecessary fragmentation and an overly broad all-purpose tool.
The surface covers the core read-only workflow: checking amounts, explaining terminology, resolving or discovering codes, and obtaining dispute or appeal guidance. However, common CPT and X12 remark codes are recognized but not described, and CPT descriptions cannot be searched, leaving some frequent EOB entries only partially decoded.
Recomputes one EOB line or claim total from the printed amounts (billed, allowed, plan paid, deductible, copay, coinsurance, non-covered, patient responsibility) and reports the contractual adjustment, the expected patient responsibility and plan payment, and any discrepancy such as a balance bill or a mismatched total. Use it when a user gives EOB or bill amounts and asks whether what they owe is right; it returns an itemized, exact calculation with stated assumptions. Pure arithmetic; takes dollar amounts only, never names or identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| copay | No | Copay amount. | |
| billed | No | Provider's billed charge for the line or claim. | |
| allowed | No | Plan's allowed, approved or eligible amount. | |
| plan_paid | No | Amount the plan paid. | |
| deductible | No | Amount applied to the deductible. | |
| in_network | No | false for an out-of-network claim. Defaults to true. | |
| non_covered | No | Non-covered amount the statement assigns to the patient (PR group), if any. | |
| coinsurance_rate | No | Coinsurance percentage, for example 20 or 0.2, if the dollar amount is not printed. | |
| coinsurance_amount | No | Coinsurance in dollars, if printed. | |
| patient_responsibility | No | Total the statement says the patient owes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuinely new behavior: it returns an itemized exact calculation with stated assumptions and flags discrepancies such as balance bills or mismatched totals, and it notes no names or identifiers are accepted. That return-shape and assumption disclosure matters because there is no output schema.
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?
Three sentences, front-loaded with what is computed, followed by when to use it and a scope/PHI boundary note. Every sentence carries information; only the closing "never names or identifiers" clause is slightly imprecise given the boolean and percentage parameters.
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 ten-parameter, all-optional arithmetic tool with no output schema, the description does the important work: it explains the computation, the reported outputs, the discrepancy detection and the assumptions. The one notable gap is minimum viable input — with no required parameters, an agent cannot tell from the description which amounts must be supplied for a meaningful recomputation.
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 each of the ten amounts is already documented, giving a baseline of 3. The description mostly restates the schema's field list rather than adding usage rules (e.g., which combinations are sufficient, how coinsurance_rate vs coinsurance_amount are reconciled). Its "dollar amounts only" claim also sits slightly awkwardly beside the in_network boolean and coinsurance_rate percentage 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?
States a specific verb and resource ("Recomputes one EOB line or claim total from the printed amounts"), enumerates the inputs it consumes, and names what it produces (contractual adjustment, expected patient responsibility and plan payment, discrepancy flags). This clearly separates it from siblings like explain_insurance_term and get_eob_reading_guide, which describe or explain rather than compute.
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?
Gives an explicit triggering condition: use when a user supplies EOB or bill amounts and asks whether what they owe is right. It also implicitly fences the tool ("pure arithmetic; takes dollar amounts only"), suggesting it is not for term definitions or document retrieval. It stops short of naming the alternative sibling for non-arithmetic questions, so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns KeepMD's plain-language definition, a worked example and related terms for an insurance or medical-billing term from its glossary (allowed amount, deductible, coinsurance, balance billing, CO/PR group codes, No Surprises Act, observation status and about 110 more). Use it when a user asks what a word, column or abbreviation on an EOB, Medicare Summary Notice or bill means, including common ones such as allowed amount, billed amount, deductible or CO. Takes one term per call.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | An insurance or billing term as it appears on the statement, for example "allowed amount", "coinsurance", "CO", "not a bill". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, and non-destructive behavior. The description adds useful context beyond that by specifying the return contents (definition, worked example, related terms), glossary breadth, and one-term-per-call constraint; it does not address unknown-term behavior or matching rules.
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 front-loads purpose, then gives usage context, then states the call constraint in three sentences. The example list is dense but relevant to retrieval, with no filler or repetitive wording.
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, one-parameter, read-only glossary lookup, the description covers purpose, trigger conditions, return contents, and call cardinality. Although there is no output schema, the description explains what is returned, so remaining details such as miss behavior are minor.
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%, and the term parameter already documents accepted input and examples. The description reinforces 'one term per call' and lists more examples, but adds little syntax or constraint beyond what the schema already provides.
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 states a specific verb and resource: it returns a plain-language definition, worked example, and related terms for an insurance or medical-billing term from KeepMD's glossary. The scope is clear, but it does not explicitly distinguish itself from siblings such as lookup_codes or search_codes.
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?
It gives an explicit trigger: use when a user asks what a word, column, or abbreviation on an EOB, Medicare Summary Notice, or bill means. It also states 'Takes one term per call,' but offers no when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns KeepMD's step-by-step guide, red flags and links to official consumer resources for reading an Explanation of Benefits (overview), resolving a bill that looks wrong (dispute), appealing a denial (appeal), or the handful of terms that drive the arithmetic (glossary). Use it when a user asks how to read an EOB, what to do about a bill that looks wrong, or how to appeal a denial.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | overview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds useful substance beyond them by disclosing the payload shape: step-by-step guide, red flags, and links to official consumer resources, which matters because there is no output schema.
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 what the tool returns and followed by when to call it. Every clause carries information (the four topics, the three content types, the three trigger scenarios) with no filler.
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 single-optional-enum, read-only lookup with no output schema, the description supplies both the return content and the usage triggers across all four topics. Nothing an agent needs in order to select and invoke it correctly is missing.
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 0%, so the description carries the burden for the single 'topic' parameter, and it does so by mapping each enum value to an intent: overview for reading an EOB, dispute for a wrong bill, appeal for a denial, glossary for arithmetic-driving terms. The mapping is conveyed implicitly through parallel parenthetical ordering rather than by naming the parameter, and the default of 'overview' is never mentioned.
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 names a specific verb and resource ('Returns KeepMD's step-by-step guide, red flags and links') and enumerates the four content areas it covers, so an agent knows exactly what comes back. It stops short of explicitly differentiating itself from the sibling explain_insurance_term, which the 'glossary' topic partially overlaps with.
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 second sentence gives concrete triggering conditions: how to read an EOB, what to do about a wrong bill, how to appeal a denial. That is clear when-to-use guidance. It names no alternatives or exclusions, so an agent facing a term-definition question has no signal for choosing this over explain_insurance_term.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks codes against the current official releases, which change every year, and reports whether each is valid, billable or terminated today. Returns the official descriptor for ICD-10-CM diagnosis codes, HCPCS Level II service/supply/drug codes and HCPCS modifiers found on an Explanation of Benefits or medical bill, plus the chapter, a plain-language note where KeepMD has one, the data version, and licensing notices for CPT, dental, NDC and X12 remark codes (which are recognized but not described). Use it for any code a user asks about, including common ones such as Z00.00, 99213, J0696 or CO-45. Accepts every code from a statement in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | Codes exactly as printed on the statement, for example ["E11.9", "J0696", "99213", "CO-45", "GT"]. Up to 50 per call; one call per statement. | |
| system | No | Which code set to assume. auto tries ICD-10-CM, HCPCS Level II and the licensed patterns. Use carc or rarc for remark/reason codes, modifier for two-character modifiers. | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real context beyond them: codes change yearly, the data version is returned, and CPT/dental/NDC/X12 remark codes are recognized but not described, which warns the agent about coverage gaps. It does not say how unrecognized or malformed codes are reported back, which is the main remaining ambiguity.
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?
Front-loaded with the core check/validity behavior, then systematically covers inputs, coverage, and caveats. It is dense rather than padded, though the inline code examples repeat what the schema already lists and could be trimmed.
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 carries the return-value burden and does so reasonably: descriptor, chapter, plain-language note, data version, licensing notices. It still doesn't state the response shape per code (e.g., results aligned with input order, per-code status field), which is the one thing an agent might need to compose a follow-up call.
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 both parameters (codes array with 1-50 items, system enum) are already fully documented, and the description's examples largely duplicate the schema's own examples. It reinforces the "one call per statement" batching intent but adds no new meaning about how system values like 'auto' resolve.
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?
Names a concrete verb and outcome ("checks codes against the current official releases... reports whether each is valid, billable or terminated today") and enumerates the supported code systems. It is unmistakably a validity lookup rather than a free-text search, but it never names the sibling search_codes, so an agent still has to infer which of the two to pick for a code question.
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?
Gives direct routing guidance: "Use it for any code a user asks about" with concrete examples (Z00.00, 99213, J0696, CO-45) and the batching rule "Accepts every code from a statement in one call." It stops short of explicit when-not-to-use conditions or pointing to search_codes / check_eob_math as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds ICD-10-CM diagnosis codes and HCPCS Level II service, supply and drug codes whose official description matches words from a statement (everyday wording such as "flu shot" or "x-ray" is translated to the clinical terms), or whose code starts with the given characters. Use it when the statement prints a description but no code, or the code is partly illegible. CPT (5-digit) physician-service codes such as office visits and lab panels are not searchable because their text is licensed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words from a service or diagnosis description in everyday or clinical wording ("flu shot", "influenza vaccine administration", "type 2 diabetes"), or the start of a code ("E11", "J069"). | |
| system | No | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description contributes real behavioral context the annotations cannot: everyday wording is translated to clinical terminology before matching, prefix matching applies to code strings, and CPT text is absent for licensing reasons. It says nothing about how results are ranked or ordered, which is the remaining 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?
Two tightly packed sentences: the capability and match modes come first, then the usage trigger and the CPT exclusion. Every clause carries information; nothing is redundant with the title or schema.
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 three-parameter read-only search with no output schema, the description covers matching behavior, acceptable input phrasing, and scope limits well. The notable omissions are the shape of the returned results and the role of the system and limit parameters, which the low schema coverage leaves undocumented anywhere.
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 only 33%: query is documented in the schema, but limit and system are not. The description clarifies the query semantics (word match vs. code-prefix match) but never mentions the limit cap or what the icd10cm/hcpcs2 system selector does beyond naming the two code families in passing. Partial compensation only, so the baseline 3 fits.
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?
States a specific verb and resource set (finds ICD-10-CM diagnosis codes and HCPCS Level II service/supply/drug codes) and defines the two match modes: official-description word match or code prefix match. It also carves out what is not covered (CPT 5-digit physician-service codes and why), so an agent can distinguish this from lookup_codes.
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?
Gives an explicit trigger: use when the statement prints a description but no code, or the code is partly illegible. It also states a clear exclusion (CPT not searchable), which prevents a wasted call. It stops short of naming the sibling lookup_codes as the exact-code alternative, so the routing is implied rather than spelled out.
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.
check_eob_mathexplain_insurance_termget_eob_reading_guidelookup_codessearch_codesMedigami: medical bill error scan, denial decoding, appeal deadlines, hospital price lookup
Is your US medical bill fair? Compares charges with Medicare rates and drafts a dispute letter.
Explains contracts, letters and tax notices clause by clause. Text, PDF or photos. Not legal advice.
Read-only Medicare Benefits Schedule lookup: items, history, relationships and combinations.
Add one secure layer between your agents and this server.