MedPrice AI

Summarize the price terms hospitals file a code under

get_code_provider_terms_summary

Read-only

Which billing classes, methodologies and settings hospitals file a (code_type, code) under, and how many hospitals each group has, so a caller can offer the choices before calling list_code_provider_hospitals or get_code_provider_price_distribution. group_by sets what each entry is a group of (default: one set of terms). A hospital filing several groups is counted in each, so don't sum the entries' hospital_count; use the top-level hospital_count for distinct hospitals. Backed by the hospital-prices serving snapshot; fails with UNAVAILABLE until the server has opened one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code_type": "<code_type>",
      "code": "<code>"
    },
    "name": "get_code_provider_terms_summary"
  }
}

Input Schema

Name	Required	Description
`code`	Yes
`group_by`	No	Which rows exist: one per billing class + methodology + setting (GROUP_BY_PER_COMBINATION, the default), per billing class, per methodology, or GROUP_BY_ALL (one figure over everything, blending billing classes), or GROUP_BY_FACILITY_PLUS_PROFESSIONAL (one row per methodology and setting the hospital files under both the facility and the professional billing class, the two added together, i.e. the combined bill; terms are methodology and setting, no billing class; no row where there is no professional counterpart). Applied before filter, which may name only the terms the grouping still keeps (e.g. GROUP_BY_BILLING_CLASS with a methodology filter, or GROUP_BY_ALL with any filter, is rejected as INVALID_ARGUMENT).
`code_type`	Yes	Code system the billing code belongs to, e.g. APR-DRG, CDM, CPT, HCPCS, MS-DRG, RC.
`min_sample_count`	No	Only count hospitals whose figure has at least this many billing records (same rule as list_code_provider_hospitals). Negative values are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

changedInput schema / properties / group_by / description

Previous value: -"Which rows exist: one per billing class + methodology + setting (GROUP_BY_PER_COMBINATION, the default), per billing class, per methodology, or GROUP_BY_ALL (one figure over everything, blending billing classes). Applied before filter, which may name only the terms the grouping still keeps (e.g. GROUP_BY_BILLING_CLASS with a methodology filter, or GROUP_BY_ALL with any filter, is rejected as INVALID_ARGUMENT)."New value: +"Which rows exist: one per billing class + methodology + setting (GROUP_BY_PER_COMBINATION, the default), per billing class, per methodology, or GROUP_BY_ALL (one figure over everything, blending billing classes), or GROUP_BY_FACILITY_PLUS_PROFESSIONAL (one row per methodology and setting the hospital files under both the facility and the professional billing class, the two added together, i.e. the combined bill; terms are methodology and setting, no billing class; no row where there is no professional counterpart). Applied before filter, which may name only the terms the grouping still keeps (e.g. GROUP_BY_BILLING_CLASS with a methodology filter, or GROUP_BY_ALL with any filter, is rejected as INVALID_ARGUMENT)."

changedInput schema / properties / group_by / enum

Previous value: -[
-  "GROUP_BY_PER_COMBINATION",
-  "GROUP_BY_BILLING_CLASS",
-  "GROUP_BY_METHODOLOGY",
-  "GROUP_BY_ALL"
-]New value: +[
+  "GROUP_BY_PER_COMBINATION",
+  "GROUP_BY_BILLING_CLASS",
+  "GROUP_BY_METHODOLOGY",
+  "GROUP_BY_ALL",
+  "GROUP_BY_FACILITY_PLUS_PROFESSIONAL"
+]

AddedNov 3, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only annotations, the description discloses important behavior: entries double-count hospitals across groups, so callers must use the top-level hospital_count for distinct hospitals. It also states the tool is backed by the hospital-prices serving snapshot and fails with UNAVAILABLE until the server has opened one.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and then covers grouping and counting caveats efficiently. It is dense but each sentence contributes useful information, with only minor overlap with the already-detailed group_by schema description.

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

Completeness5/5

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

Given the absence of an output schema, the description still explains the return shape well enough: grouped billing classes, methodologies and settings with per-group hospital counts and a distinct top-level hospital_count. It also covers the serving-snapshot dependency and the UNAVAILABLE failure mode, which are the key operational details for this tool.

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

Parameters3/5

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

Schema description coverage is 75%, so the schema already explains group_by in detail, including all enum values, and describes code_type and min_sample_count. The description adds a brief note that group_by controls what each entry is a group of, but does not explain the undocumented code parameter or add much beyond the schema.

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 states a specific resource: billing classes, methodologies and settings hospitals file a (code_type, code) under, with hospital counts per group. It explicitly distinguishes the tool from siblings by positioning it as the choice-offering step before list_code_provider_hospitals or get_code_provider_price_distribution.

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?

It gives clear usage context by saying the caller can offer the choices before calling the two named sibling tools, which routes the agent well. It does not explicitly state when not to use the tool, but the alternatives and sequencing are clear.

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

All MedPrice AI tools Inspect

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.