Search source-labeled hospital prices, CPT codes, providers, and healthcare cost estimates.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: search tools cover different entities, pricing tools cover different scenarios (hospital, market, estimate), and the explanation and update tools are unique. No two tools overlap in function.
Most tools follow a verb_noun pattern (get_, search_, explain_, suggest_, submit_), which is clear and predictable. However, the verbs are not uniform across all tools (e.g., 'get' vs 'search' for lookups), introducing slight inconsistency.
With 12 tools, the server is well-scoped for healthcare pricing. Each tool serves a necessary function—search, pricing variations, profile, explanation, and updates—without excess or deficiency.
The tool surface covers the full workflow: entity/code searching, multiple pricing queries, price source explanation, entity profiles, and update submissions. No obvious gaps for the intended domain.
explain_price_sourcesExplain Price SourcesAExplain the source labels, provenance, confidence, and caveats behind Loa prices for one hospital or provider entity. Use this when an agent needs to tell a user why prices are MRF-published, Loa-reviewed, estimated, or unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact Loa entity slug from search_entities. | |
| limit | No | Maximum number of prices to inspect, default 50, max 100. | |
| cpt_codes | No | Optional CPT codes to explain. If omitted, explains current indexed prices. |
| Name | Required | Description |
|---|---|---|
| entity | Yes | |
| caveats | Yes | |
| cpt_codes | Yes | |
| provenance | Yes | |
| price_count | Yes | |
| source_summary | Yes | |
| comparable_mrf_price_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying the content of the explanation (source labels, provenance, confidence, caveats), which goes beyond the annotations without contradicting them.
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 that immediately convey the tool's purpose and usage. There is no wasted text, and the key information is front-loaded.
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 moderate complexity and the presence of an output schema (not shown), the description adequately covers what the tool does and when to use it. It mentions the types of information provided (source labels, provenance, confidence, caveats), which is sufficient for an agent to decide to invoke it. However, it could benefit from a brief mention of the output format or structure, but the output schema compensates.
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 all three parameters having descriptions in the input schema. The tool description adds overall context but does not provide additional meaning beyond what the schema already offers for each parameter, so the baseline score 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?
The description clearly states the tool's purpose: explaining source labels, provenance, confidence, and caveats behind Loa prices for a single entity. It distinguishes itself from sibling tools like get_entity_prices (which retrieves prices) and get_pricing_estimate (which estimates) by focusing on the provenance and explanation of price sources.
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 explicitly states when to use the tool: 'when an agent needs to tell a user why prices are MRF-published, Loa-reviewed, estimated, or unavailable.' This provides clear guidance, though it doesn't mention when not to use it or list specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entity_pricesEntity PricesAReturn source-labeled prices for a Loa hospital or provider entity slug using the shared resolver. Use search_entities first if the slug is unknown. Results include provenance and explicit unavailable rows for requested CPT codes with no current price.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact Loa entity slug from search_entities or a Loa SEO page. | |
| limit | No | Maximum number of prices, default 50, max 100. | |
| cpt_codes | No | Optional CPT codes to filter. If omitted, returns current indexed prices up to the limit. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| entity | Yes | |
| prices | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds that results include provenance and explicit unavailable rows for missing CPT codes, which is valuable beyond the structured annotations.
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 the core purpose, no redundancy. Each sentence adds distinct value.
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 annotations and output schema, the description covers essential behavior (provenance, unavailable rows) and usage context. Could mention limit behavior or edge cases, but overall sufficient for effective use.
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 parameters are already documented. Description adds minor context for slug (where to get it) but does not significantly enhance the schema descriptions for limit or cpt_codes.
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 returns source-labeled prices for a Loa entity slug, specifying verb and resource. Distinguishes from siblings by mentioning the shared resolver and prerequisite search_entities.
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 advises to use search_entities first if the slug is unknown. While it doesn't exhaustively list when not to use, this provides clear context for a common scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entity_profileEntity ProfileAReturn one Loa hospital or provider entity profile by exact slug or entity_pages.id. Includes profile-field provenance so agents can distinguish source-file fields from Loa-reviewed overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Exact Loa entity slug or entity_pages.id from search_entities. | |
| entity_type | No | Optional disambiguation when slug_or_id is a slug. |
| Name | Required | Description |
|---|---|---|
| entity | Yes | |
| provenance | Yes | |
| profile_provenance | Yes | |
| profile_field_provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds valuable behavioral detail about provenance (distinguishing source files from overrides) beyond what annotations provide. No contradictions.
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, directly stating action and unique feature. No unnecessary words; front-loaded with core purpose. Highly 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?
Covers purpose, method, and key output feature. Given low complexity and presence of output schema, it is mostly complete. Could mention error handling for missing entities, but not required.
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?
With 100% schema coverage, both parameters are fully described in the schema. The description does not add additional parameter semantics beyond what the schema provides, meeting the baseline expectation.
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 returns a single entity profile by exact slug or ID, and distinguishes itself from sibling search tools like 'search_entities' by specifying exact lookup. The mention of provenance adds unique value.
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?
Implicitly guides use when exact slug/ID is known, but lacks explicit comparison to siblings like 'search_entities'. The context signals provide sibling names which partially compensate, but the description itself could better state 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.
get_hospital_pricingHospital PricingAHospital-specific pricing tool for source-labeled Loa runtime data. Returns source-labeled Published MRF prices and Loa Verified Provider Price overlays for CPT codes, including cash/self-pay and payer-negotiated rates when available. Use this when comparing named hospitals or checking a quoted hospital price against available source rows.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt_codes | Yes | CPT procedure codes to look up pricing for | |
| hospital_ids | Yes | Hospital IDs from search_hospitals results |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| pricing | Yes | |
| provenance | Yes | |
| services_found | Yes | |
| hospitals_found | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the description adds value by specifying data sources (MRF, Loa verified) but does not provide additional behavioral insights beyond annotations.
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 purpose and use case. No redundant 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?
Given output schema exists, description adequately explains return types (published MRF, verified overlays, cash/self-pay, negotiated rates) and use case. Complete for a read-only data retrieval 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 coverage is 100% with clear parameter descriptions. The description does not add new semantics beyond mentioning CPT codes and hospital-specific context already implied by 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?
Clearly states it is a hospital-specific pricing tool returning source-labeled Published MRF prices and Loa Verified Provider Price overlays for CPT codes. Differentiates from siblings like get_market_pricing by emphasizing hospital-specific and named hospitals.
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 states when to use: when comparing named hospitals or checking a quoted hospital price. Does not mention when not to use or alternative tools for broader pricing queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_pricingMarket PricingAPreferred benchmark pricing tool. Returns market cash/self-pay and insurance-negotiated price summaries for CPT codes, aggregated from Loa's hospital price-transparency dataset. Use this when the user wants source-grounded regional or national market pricing rather than a single-hospital rate.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State for regional pricing (e.g. "CA", "New York"). Unknown states return McpToolInvalidInput. Valid states with no regional data fall back to national averages. | |
| zip_code | No | ZIP code (used with state for location context) | |
| cpt_codes | Yes | CPT codes to look up (e.g. ["99213", "93000"]) |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| pricing | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive; description adds data source (Loa's hospital price-transparency dataset) and aggregation nature. No contradictions. Output schema exists so return format is covered.
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: first explains what tool does and data source, second gives usage guidance. Front-loaded, concise, no fluff.
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 tool has 3 parameters, full schema coverage, and output schema, description provides sufficient context: purpose, data source, when to use, and implicit alternatives. No gaps.
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 each parameter (state, zip_code, cpt_codes). Description does not add new param details beyond what schema provides, so 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?
Description states it returns market cash/self-pay and insurance-negotiated price summaries for CPT codes, aggregated from Loa's dataset. It distinguishes from siblings by positioning as 'preferred benchmark' and contrasting with 'single-hospital rate', making purpose clear.
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 'Use this when the user wants source-grounded regional or national market pricing rather than a single-hospital rate', providing clear context for when to use. Does not list exclusions but sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricing_estimatePricing EstimateAQuick directional estimate for one or more CPT codes. Prefers observed national market pricing derived from hospital price-transparency data, but falls back to a broad CPT-range heuristic when observed pricing is missing. Use this for a fast ballpark total. For source-grounded market benchmarks or hospital-specific source-labeled prices, prefer get_market_pricing or get_hospital_pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | No | ZIP code for regional pricing (defaults to national average) | |
| procedure_codes | Yes | CPT procedure codes to price (e.g. ["99213", "85025"]) |
| Name | Required | Description |
|---|---|---|
| zipCode | Yes | |
| disclaimer | Yes | |
| procedures | Yes | |
| provenance | Yes | |
| estimatedCost | Yes | |
| containsHeuristicEstimates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. Description adds value by detailing data source preference (observed pricing) and fallback heuristic, which is beyond annotation coverage. No contradictions.
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, each distinct and valuable: purpose, behavioral details, and usage guidance. No fluff, efficiently conveys key 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?
For a simple read-only estimate tool with output schema present, description covers purpose, data sources, fallback, and usage alternatives. No critical missing information.
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?
Input schema has 100% description coverage, providing clear parameter definitions. Description adds little beyond mentioning CPT codes and regional pricing, not compensating for gaps since schema is already complete.
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 provides a quick directional estimate for CPT codes using observed data with a fallback heuristic. Explicitly distinguishes itself from sibling tools by advising when to use get_market_pricing or get_hospital_pricing.
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 'Use this for a fast ballpark total' and advises preferring alternative tools for specific needs, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cpt_codesCPT Code SearchACanonical code-lookup tool for this server. Search Loa's CPT/HCPCS index using exact codes, clinical terms, or consumer phrases. Use this first when the user does not already know the CPT code, before calling pricing tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default 10, max 25) | |
| query | Yes | Search query, procedure name, medical term, or CPT code number (e.g. "knee MRI", "blood work", "99213") | |
| category | No | Filter by category: "evaluation_management", "laboratory", "radiology", "surgery", "preventive" | |
| specialty | No | Filter by medical specialty (e.g. "cardiology", "dermatology") |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| results | Yes | |
| category | Yes | |
| specialty | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent traits. The description adds the term 'canonical' and implies authoritative search behavior. No contradiction, but lacks details on edge cases (e.g., no results). Still sufficient given annotation coverage.
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 the core purpose. Every sentence adds value: first defines identity, second provides usage context.
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 search tool with 4 fully described parameters, an output schema present, and no nested objects, the description is complete. It covers purpose, usage, and search modes without missing critical information.
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 well-described parameters. The description adds value by explaining the search modes ('exact codes, clinical terms, or consumer phrases') and emphasizing it's the canonical tool, which is not in 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 verb ('search'), resource ('CPT/HCPCS index'), and scope ('canonical code-lookup tool'). It explicitly distinguishes from sibling pricing tools by positioning it as the first lookup.
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?
Explicit guidance: 'Use this first when the user does not already know the CPT code, before calling pricing tools.' This clearly defines when to use and hints at alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesEntity SearchASearch Loa runtime hospital and provider entity pages by name or state. Use this before get_entity_prices when the user names a hospital or provider but does not know the exact Loa slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results, default 20, max 50. | |
| query | No | Hospital or provider name to search for. | |
| state | No | Two-letter state code or full state name, e.g. CA or New York. | |
| entity_type | No | Optional filter for hospital or provider entities. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| entities | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds useful context about searching runtime entity pages and finding slugs, but no additional behavioral traits beyond annotations.
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: the first states the action, the second provides critical usage guidance. 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 4 parameters (all described in schema), output schema exists, and annotations are present, the description is complete: it covers purpose, usage, and behavior adequately.
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 the schema already documents all 4 parameters. The description mentions searching by name or state, which aligns with the query and state params but does not add new 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 searches Loa runtime hospital and provider entity pages by name or state, and distinguishes it from siblings by noting it is used before get_entity_prices when the exact slug is unknown.
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?
Explicit guidance: 'Use this before get_entity_prices when the user names a hospital or provider but does not know the exact Loa slug.' This tells exactly when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hospitalsHospital SearchASearch Loa's hospital directory by name or location and return hospital IDs plus address details. Use the returned hospital_ids with get_hospital_pricing to fetch source-labeled Published MRF and reviewed overlay prices.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| name | No | Hospital name to search for | |
| limit | No | Max results (default 20) | |
| state | No | Two-letter state code or full state name, e.g. "CA" or "New York". | |
| zip_code | No | ZIP code |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| hospitals | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by stating the return includes hospital IDs and address details, plus linking to a follow-up tool. No contradictions.
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, each essential. First sentence states purpose and output, second gives actionable usage guidance. 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?
The description is complete for this tool: specifies search scope, output, and integration with a related tool. With output schema present, no need for return format details. Covers key use case well.
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 descriptive parameter names and descriptions. The description only generalizes as 'by name or location', adding no significant new meaning beyond the schema. 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?
Description explicitly states 'Search Loa's hospital directory by name or location' with clear verb and resource, and distinguishes from siblings by specifying outputs used with get_hospital_pricing. It clearly differentiates from broader sibling tools like search_entities.
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?
Description explicitly instructs to use returned hospital_ids with get_hospital_pricing for pricing data, providing concrete guidance. It does not explicitly state when not to use alternatives, but the context and purpose are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_providersProvider SearchASearch public CMS NPI Registry data for clinicians and healthcare organizations by specialty, name, or location. Use returned provenance to understand the registry source and scope. Use this for provider lookup, not pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Provider name to search for (e.g. "John Smith") | |
| limit | No | Max results (default 20) | |
| location | No | Location to search in | |
| specialty | No | Medical specialty (e.g. "Cardiology", "Family Medicine") |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| providers | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, idempotentHint, destructiveHint). Description adds provenance note and data source, but no contradictions. With annotations present, a score of 3 is appropriate.
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: first states core function, second provides usage guidance. No redundancy or 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?
Given annotations and output schema, description adds enough context about data source and usage. Slightly more detail about return structure would push to 5.
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 descriptions for all parameters. Description merely lists criteria without adding extra meaning; baseline 3 is correct.
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?
Explicitly states verb 'Search', resource 'public CMS NPI Registry data for clinicians and healthcare organizations', and search criteria (specialty, name, or location). Distinguishes from sibling tools like search_entities, search_hospitals, and pricing tools via 'not pricing'.
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?
Provides clear context: 'Use this for provider lookup, not pricing.' Implicitly contrasts with sibling pricing tools, though alternatives are not explicitly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_entity_update_requestSubmit Entity Update RequestASubmit a profile, listing, or price correction for Loa review without requiring a provider portal. This is the only mutating provider/entity tool. It requires OAuth, captures submitter and source evidence, records linked-provider status when available, and never changes public data until Loa approves the request.
| Name | Required | Description | Default |
|---|---|---|---|
| attestation | No | How the submitter is connected to the submitted evidence. | |
| entity_slug | No | Exact Loa entity slug if entity_page_id is not available. | |
| entity_type | No | Entity kind for the requested update; use unknown only when it cannot be determined. | unknown |
| price_items | No | Optional structured price rows proposed for Loa review. | |
| source_urls | No | Optional public URLs reviewers can use to verify the submitted change. | |
| request_type | Yes | Type of reviewed change being requested. | |
| source_notes | No | Short verification notes, source context, or callback instructions. | |
| entity_page_id | No | Loa entity_pages.id for the provider or hospital. | |
| submitter_name | No | Name of the person submitting the request. | |
| submitter_role | No | Submitter role, such as billing manager or authorized agent. | |
| idempotency_key | No | Optional stable retry key. Loa derives one from the payload if omitted. | |
| submitter_email | Yes | Work email for the submitting representative. | |
| submitter_phone | No | Optional callback phone number for reviewer follow-up. | |
| proposed_changes | No | Structured profile or listing fields proposed for Loa review. | |
| uploaded_file_url | No | Optional public URL for an uploaded evidence file. | |
| submitter_organization | No | Provider, hospital, or agent organization represented by the submitter. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| requestId | Yes | |
| entityPageId | Yes | |
| reusedExisting | Yes | |
| updateRequestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that public data is never changed until Loa approval, aligns with non-destructive annotation, and adds details about capturing submitter/source evidence and linked-provider status, going beyond annotations.
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 succinct sentences front-load the purpose, uniqueness, and key behaviors with no 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?
For a complex 16-parameter tool with nested objects and an output schema, the description covers mutability, auth, and workflow. Lacks error or result details, but output schema likely covers return values.
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 descriptions for all parameters. The description adds no parameter-specific details beyond general behavioral context, so 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 submits profile, listing, or price corrections for review, and identifies itself as the only mutating provider/entity tool, distinguishing it from all read-only siblings.
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 explicitly states this is the only mutating tool, implying use for modifications, and mentions OAuth requirement. It implicitly differentiates from read-only siblings but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_proceduresProcedure SuggestionsAAdvisory helper that suggests likely CPT codes from a plain-English medical need. Uses Loa heuristics plus AI and is not authoritative or diagnostic. Use only when the user cannot name the procedure, then confirm candidates with search_cpt_codes before pricing them. Requires a LOA account.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of the medical need (e.g. "I have a rash on my arm", "need imaging for my lower back pain") |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| provenance | Yes | |
| interpretation | Yes | |
| suggestedCodes | Yes | |
| needsConfirmationWith | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior. The description adds valuable context: uses 'Loa heuristics plus AI', is 'not authoritative or diagnostic', and requires an account. No contradiction with annotations.
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 concise sentences: purpose, usage guidelines, and requirement. Front-loaded with main function, zero superfluous 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?
Despite having an output schema, the description covers all needed context: when to use, how to follow up, non-authoritative nature, and account requirement. No gaps for such a simple 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?
Only one parameter (query) with 100% schema coverage, including an example in the description. The description adds a plain-English interpretation and example, slightly enhancing the schema's definition.
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 suggests CPT codes from plain-English medical needs, using 'suggests likely CPT codes' as the verb-resource pair. It distinguishes from siblings like search_cpt_codes by specifying the use case.
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 states when to use ('only when the user cannot name the procedure'), what to do after ('confirm candidates with search_cpt_codes before pricing'), and a prerequisite ('Requires a LOA account'). This provides clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
