Find 76,000+ curated healthcare service vendors across 25 categories and all 50 US states.
Scored across 5 tools
The tools mostly have distinct roles: category listing, provider search, ranked matching, provider detail, and EHR product detail. However, match_practice and search_providers both return vendor lists, and get_provider_detail and get_ehr_product_detail are both detail lookups, so an agent could occasionally confuse them despite the descriptions clarifying the intended use.
All tool names use consistent snake_case with a clear verb_noun pattern: get_ehr_product_detail, get_provider_detail, list_categories, match_practice, search_providers. The compound get_ehr_product_detail is slightly longer but still predictable and readable.
Five tools are well-scoped for a read-only healthcare vendor finder. Each tool covers a distinct part of the discovery flow: taxonomy, browsing, ranking, provider profiles, and EHR product records.
The vendor discovery surface is largely complete: categories, search, scored matching, and provider detail cover the main read-only workflows. A minor gap is that get_ehr_product_detail requires an exact product key, but no tool is provided to list or discover EHR product keys, which could be a dead end in some workflows.
Read the free versioned EHR product JSON projection by exact product key. Returns the complete HTTP JSON body, including explicit edition records, facts, plans, conditions, sources and publication metadata. Optional edition_key validates an explicit identity under this product; the full product response is returned unchanged. No alias resolution, edition inheritance, calculation or ranking. Unknown values and open bounds remain unchanged. Company profiles use get_provider_detail.
| Name | Required | Description | Default |
|---|---|---|---|
| edition_key | No | Optional exact edition key explicitly recorded under this product. Does not filter or merge facts. | |
| product_key | Yes | Exact P1 product key; aliases are not accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile, yet the description adds substantial semantics: the response is the complete HTTP JSON body enumerating editions, facts, plans, conditions and sources; edition_key validates identity but does not filter or merge; unknown values and open bounds are passed through unchanged. This is exactly the kind of non-obvious behavior an agent cannot infer from readOnly/idempotent hints.
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 action and return shape, and every clause carries information (no-alias, no-inheritance, no-ranking, passthrough of unknown values). It is dense and jargon-heavy, requiring careful parsing, but not padded.
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 supplies the return-shape contract itself (full JSON body with editions, facts, plans, conditions, sources, publication metadata) and covers the notable exclusions. Nothing an agent needs to invoke it correctly appears 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 coverage is 100%, so the baseline is 3 and the schema already documents both keys. The description nonetheless reinforces the counterintuitive contract that edition_key is a validation-only identity check returning the unchanged full product, and restates that aliases are not accepted for product_key.
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 (Read) and resource (versioned EHR product JSON projection) with the exact access path (exact product key), and explicitly contrasts with get_provider_detail for company profiles. An agent can distinguish this from search/match siblings without opening the schema.
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 rules out alias resolution, edition inheritance, calculation and ranking, and routes company-profile requests to get_provider_detail. It implies exact-key lookup versus search_providers but never states what to do when the key is unknown, so one alternative is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full profile of one healthcare vendor by slug. Use this after match_practice or search_providers when the user asks to "tell me more about [vendor]", "what services does [vendor] offer", "where did GPH get this information", or wants contact info or services for a specific provider. Returns company_name, category, city/state, quality_score (0-100; profile completeness, not a quality rating; 0 means never scored), description, services offered, practice_size_fit, phone and website where listed, Google rating and Google review count where present, a Provenance section that labels each fact GPH-researched, Vendor-supplied, GPH-verified or GPH conclusion with its last-checked date where one exists, and the profile URL. No listing carries a verified badge: the legacy verified flag is not a recorded check and is not shown. Where a vendor has been enrichment-extracted, the description, services and practice-size fit come from that extraction, the profile adds certifications and compliance attestations, locations served and founding year where extracted, and the response states the extraction confidence and what it was grounded in (where the extraction abstained on practice-size fit, the legacy listing value is returned and labelled as not extracted); otherwise the legacy listing fields are returned. Slug comes from match_practice or search_providers results; returns an error if the slug is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Provider slug identifier (e.g. 'ams-solutions-inc-dallas-tx'). Obtained from match_practice or search_providers response. |
| Name | Required | Description |
|---|---|---|
| ids | No | Absent when isError. |
| count | No | Always 1 on success; absent when isError. |
| content | Yes | |
| isError | No | Present and true only when the slug is unknown or the fetch fails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent annotations already covering the safety profile, the description still adds substantial behavioral context: the Provenance labelling scheme, the statement that no listing carries a verified badge (explicitly countering the legacy flag), and the enrichment-extraction fallback rules including confidence reporting. It does not, however, discuss rate limits, caching, or pagination, so it stops short of full disclosure.
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 first two sentences are tightly front-loaded and earn their place. The remainder is a long, dense enumeration of return fields that largely duplicates the output schema, and the enrichment-extraction sentence is a run-on that is hard to parse on first read.
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 read-only single-param lookup with an output schema and full annotation coverage, the description supplies everything an agent needs: when to call it, where the slug comes from, failure behavior, and the nuanced semantics of provenance and extraction-sourced fields.
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% on a single param, so the baseline is 3. The description adds real value beyond the schema by naming the originating tools for the slug and stating that an unknown slug returns an error, which the schema alone does not convey.
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?
Opens with a specific verb+resource+scope: 'Get the full profile of one healthcare vendor by slug.' It is immediately distinguishable from the sibling tools, which are named as the sources that produce the slug. No ambiguity about what is retrieved.
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 to use it 'after match_practice or search_providers' and enumerates the user phrasings that should trigger it ('tell me more about [vendor]', 'what services does [vendor] offer', etc.). It also states the unknown-slug error condition, so the agent knows the failure mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every service category in the GPH vendor directory with its live provider count. Call this FIRST when you do not already know which category fits the user's need, when a category search returned nothing, or when the user asks what kinds of vendors are available. Returns all 25 categories with {category, slug, providers}. The category names returned here are the exact values match_practice and search_providers expect (common aliases also resolve). Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | Number of categories returned; absent when isError. |
| content | Yes | |
| isError | No | Present and true only on failure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful context: it returns 25 categories with a live provider count, includes a 'slug', and states that category names are exact values accepted by other tools (with aliases resolving). This goes beyond the annotations by clarifying output scope and cross-tool compatibility.
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 core purpose, then delivers usage guidance, output format, and compatibility in a compact manner. Every sentence adds value; there is no repetition of annotations or schema details.
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, parameter-less list tool, the description is fully complete. It covers what, when, and how the output can be used, and given an output schema exists, there is no need to detail return values further. The compatibility note with sibling tools provides essential context for an agent selecting the right 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?
The tool takes no parameters, and the schema is empty. The description explicitly states 'Takes no arguments,' which eliminates any ambiguity. With zero parameters, the baseline is 4, and the description confirms this clearly without unnecessary detail.
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 with a specific verb and resource: 'List every service category in the GPH vendor directory with its live provider count.' It distinguishes itself from sibling tools (get_provider_detail, match_practice, search_providers) by emphasizing it lists all categories rather than searching or matching, and by explicitly positioning itself as the entry point.
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 explicit when-to-use guidance: 'Call this FIRST when you do not already know which category fits the user's need, when a category search returned nothing, or when the user asks what kinds of vendors are available.' It also notes compatibility with match_practice and search_providers, giving clear direction on how this tool relates to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend and rank the best healthcare vendors for a specific medical practice. Use this when a practice manager, physician, or administrator asks for a recommendation, e.g. "recommend a medical billing / RCM company for my practice", "who should I use for credentialing / payer enrollment", "find an EHR for my small [specialty] practice", or "which practice-management software fits a [size] practice in [city, state]". Scores and ranks providers against the practice profile (specialty, size, location, EHR system, budget) and returns up to 5 merit-ranked matches (completeness-scored, no paid placement) with {company_name, category, city, state_abbr, quality_score (0-100; profile completeness -- how many listing fields are filled in -- not a quality or reputation rating; 0 means never scored), final_score (0-100), description, website, profile_url, slug}. Use service_needs to specify up to six controlled service codes for staffing, billing or credentialing; codes must belong to the requested category. Use vendor_geo_preference to prefer local or state vendors, allow national vendors, or request only national or explicitly serves-your-state vendors. State is the practice location and may be omitted only with NATIONAL_OK or NATIONAL_ONLY; category remains required. Capability evidence, geography basis, profile extraction date and service-need coverage are returned where available; missing evidence is unknown, never a verified or paid badge. For open-ended browsing without a practice profile, use search_providers. Pass a match's slug to get_provider_detail for the full profile.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City where the practice is located. Send city and state separately, not as a combined `location` string. | |
| state | No | Practice location as a two-letter state abbreviation (e.g. 'TX', 'CA', 'NY'). Required unless vendor_geo_preference is NATIONAL_OK or NATIONAL_ONLY. Send as `state`, not `state_abbr` (`state_abbr` is an output field name only). | |
| category | Yes | Service category needed. One of the 25 categories: 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Consulting', 'Healthcare Legal Services', 'Healthcare CPA & Tax Advisory', 'Medical Coding Services', 'Healthcare Staffing & Recruiting', 'Healthcare Marketing & Reputation Management', 'Compliance & HIPAA Services', 'Medical Equipment & Supplies', 'Healthcare Real Estate & Site Selection', 'Practice Financing & Loans', 'Healthcare Construction & Facilities', 'Healthcare Signage & Wayfinding', 'Medical Waste & Environmental Services', 'Healthcare Insurance & Malpractice Brokers', 'Practice Valuation & Brokerage', 'Patient Financing & Payment Solutions', 'Medical Transcription & Documentation', 'Pharmacy & Medication Management', 'Telehealth & Virtual Care Infrastructure', 'Laboratory & Diagnostics Services', 'Group Purchasing Organizations (GPOs)', 'Healthcare PR & Communications'. Common aliases also resolve (e.g. 'billing', 'RCM', 'EHR', 'credentialing'). Call list_categories for the live list with provider counts. | |
| specialty | No | Medical specialty of the practice (e.g. 'Family Medicine', 'Cardiology', 'Pediatrics', 'Dermatology') | |
| ehr_system | No | EHR system used by the practice (e.g. 'Epic', 'athenahealth', 'AdvancedMD', 'eClinicalWorks'). Helps score providers with compatible integrations higher. | |
| budget_range | No | Approximate monthly budget | |
| practice_size | No | Size of the practice by provider count. The parameter is named `practice_size`, not `size`. | |
| service_needs | No | Up to six distinct controlled service codes, never free text. STAFFING_* codes apply to Healthcare Staffing & Recruiting, BILLING_* codes to Medical Billing & RCM, and CRED_* codes to Credentialing Services (including aliases). Within a staffing facet codes are alternatives; across facets they ask for combined coverage. Un-evidenced needs are unknown and never exclude a vendor. | |
| vendor_geo_preference | No | Vendor geography preference, separate from practice location: LOCAL_PREFERRED prefers same-city vendors, STATE_PREFERRED prefers in-state vendors, NATIONAL_OK allows national vendors to compete across geography tiers, and NATIONAL_ONLY restricts eligibility to national or explicitly serves-your-state vendors. State may be omitted for NATIONAL_OK or NATIONAL_ONLY. |
| Name | Required | Description |
|---|---|---|
| ids | No | Absent when isError. |
| count | No | Total scored candidates before the top-5 slice; absent when isError. |
| content | Yes | |
| isError | No | Present and true only on failure (match request error or no candidates). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on real behavioral context: results are capped at 5, ranked by merit with 'no paid placement', quality_score is defined as profile completeness rather than a reputation rating, and missing evidence is 'unknown, never a verified or paid badge'.
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?
Purpose and when-to-use are front-loaded and nearly every sentence carries routing or constraint information. It is dense and slightly over-long, and the enumerated result fields ({company_name, category, ...}) duplicate what the output schema already provides.
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 9-parameter, enum-heavy matching tool with an output schema present, the description covers selection, parameter interaction (geo preference vs. state requirement), result semantics, and adjacent tools. Nothing an agent needs to 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 coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics the schema does not: service_needs codes must belong to the requested category, caps at six, facets are alternatives within a facet but combined across facets, and state may only be omitted with NATIONAL_OK/NATIONAL_ONLY.
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+resource combo: 'Recommend and rank the best healthcare vendors for a specific medical practice.' It also explicitly separates itself from siblings by naming search_providers for open-ended browsing and get_provider_detail for full profiles, so an agent can route without opening any schema.
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 concrete when-to-use triggers with verbatim user phrasings (billing/RCM recommendation, credentialing, EHR for a specialty, practice-management software by size/city) and an explicit alternative (search_providers) for the case where no practice profile exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter the healthcare vendor directory. Use this for open-ended exploration, e.g. "show me medical billing companies in Texas", "list credentialing services", "what EHR vendors are there for cardiology", or when the user wants to page through options rather than get a scored shortlist. Paginated results filtered by category, location, minimum profile-completeness score, curated Tier-1 grade, and practice-size fit; returns a page of providers with {company_name, category, city, state_abbr, quality_score (0-100; profile completeness, not a quality rating; 0 means never scored), contact info, slug}. For a scored recommendation to a specific practice profile, use match_practice instead. Pass a returned slug to get_provider_detail for the full profile.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to filter by. Matches one exact city only: the value is compared as a city slug (case and punctuation ignored, e.g. 'San Antonio' matches 'san-antonio'); partial names and prefixes do not match. | |
| page | No | Page number for pagination (default 1) | |
| state | No | Two-letter state abbreviation (e.g. 'TX'). Send as `state`, not `state_abbr` (`state_abbr` is an output field name only). National providers always included. | |
| category | Yes | Service category to search. One of the 25 categories: 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Consulting', 'Healthcare Legal Services', 'Healthcare CPA & Tax Advisory', 'Medical Coding Services', 'Healthcare Staffing & Recruiting', 'Healthcare Marketing & Reputation Management', 'Compliance & HIPAA Services', 'Medical Equipment & Supplies', 'Healthcare Real Estate & Site Selection', 'Practice Financing & Loans', 'Healthcare Construction & Facilities', 'Healthcare Signage & Wayfinding', 'Medical Waste & Environmental Services', 'Healthcare Insurance & Malpractice Brokers', 'Practice Valuation & Brokerage', 'Patient Financing & Payment Solutions', 'Medical Transcription & Documentation', 'Pharmacy & Medication Management', 'Telehealth & Virtual Care Infrastructure', 'Laboratory & Diagnostics Services', 'Group Purchasing Organizations (GPOs)', 'Healthcare PR & Communications'. Common aliases also resolve (e.g. 'billing', 'RCM', 'EHR', 'credentialing'). Call list_categories for the live list with provider counts. This tool does NOT accept a specialty filter -- use match_practice for specialty-aware ranking. | |
| per_page | No | Results per page (1-25, default 10) | |
| min_rating | No | Minimum profile-completeness score (0-100; how many listing fields are filled in, not a quality or reputation rating). Most providers score 50-85. The parameter is named `min_rating`, not `min_quality_score`. | |
| tier1_grade | No | Filter to the curated Tier-1 provider set by grade: 'A' (top-graded) or 'B' (strong). Tier-1 is a hand-reviewed ~4,400-provider subset; most directory records are not Tier-1, so this narrows results sharply. Omit to search the full directory. | |
| practice_size_fit | No | Filter providers by the practice size they best serve, on the directory's one closed vocabulary: Solo, Small, Mid-size, Large, All. The filter reads the extracted size where one exists and the listing's stated fit otherwise; a listing stating 'Solo/Small' answers both Solo and Small. 'All' means the vendor serves every size -- on listings that were never extracted it is also the default, so it narrows results little. |
| Name | Required | Description |
|---|---|---|
| ids | No | Absent when isError. |
| count | No | Total matching providers across all pages; absent when isError. |
| content | Yes | |
| isError | No | Present and true only on failure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context: pagination, the returned field set, that quality_score is profile completeness not quality (0 = never scored), and that tier1_grade narrows sharply to a hand-reviewed ~4,400 subset.
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 purpose and the routing decision, then return shape and parameter caveats. Slightly dense with redundant example queries and some restatement of schema notes, but every 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?
An output schema exists, yet the description still conveys return shape and the slug handoff; parameter caveats (aliases, enum vocabularies, filter interactions) are covered. Nothing needed to call 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 coverage is already 100%, so the baseline is 3. The description adds genuine beyond-schema meaning: the quality_score caveat, the 'not a quality rating' framing for min_rating, and the negative constraint that no specialty filter exists here.
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+resource ('Browse and filter the healthcare vendor directory') and explicitly distinguishes itself from match_practice (scored shortlist) and get_provider_detail (full profile via slug). An agent can route correctly without opening a schema.
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?
Names the exact conditions for use ('open-ended exploration', paging through options) and the exclusion ('rather than get a scored shortlist'), then points to match_practice for specialty-aware/scored ranking. Also explains the follow-up path to get_provider_detail.
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.
get_ehr_product_detailmatch_practice5 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "state"
+ ]
+ },
+ {
+ "properties": {
+ "vendor_geo_preference": {
+ "enum": [
+ "NATIONAL_OK",
+ "NATIONAL_ONLY"
+ ]
+ }
+ },
+ "required": [
+ "vendor_geo_preference"
+ ]
+ }
+]Input schema / properties / service_needsAdded value: +{
+ "description": "Up to six distinct controlled service codes, never free text. STAFFING_* codes apply to Healthcare Staffing & Recruiting, BILLING_* codes to Medical Billing & RCM, and CRED_* codes to Credentialing Services (including aliases). Within a staffing facet codes are alternatives; across facets they ask for combined coverage. Un-evidenced needs are unknown and never exclude a vendor.",
+ "items": {
+ "enum": [
+ "STAFFING_ROLE_NP",
+ "STAFFING_ROLE_PA",
+ "STAFFING_ROLE_APP",
+ "STAFFING_ROLE_PHYSICIAN",
+ "STAFFING_ROLE_RN",
+ "STAFFING_ROLE_ALLIED",
+ "STAFFING_ROLE_CLINICAL_SUPPORT",
+ "STAFFING_ENG_PERMANENT",
+ "STAFFING_ENG_LOCUM",
+ "STAFFING_ENG_TEMPORARY",
+ "STAFFING_ENG_TEMP_TO_HIRE",
+ "STAFFING_ENG_PRN",
+ "STAFFING_SET_URGENT_CARE",
+ "STAFFING_SET_OUTPATIENT",
+ "STAFFING_SET_PRIMARY_CARE",
+ "STAFFING_SET_EMERGENCY",
+ "STAFFING_SET_INPATIENT",
+ "BILLING_SCOPE_FULL_RCM",
+ "BILLING_SCOPE_CLAIMS_SUBMISSION",
+ "BILLING_SCOPE_DENIAL_MANAGEMENT",
+ "BILLING_SCOPE_AR_FOLLOWUP",
+ "BILLING_SCOPE_PATIENT_BILLING",
+ "BILLING_SCOPE_CHARGE_CAPTURE",
+ "BILLING_SCOPE_ELIGIBILITY_VERIFICATION",
+ "BILLING_SCOPE_CODING",
+ "CRED_PAYER_ENROLLMENT",
+ "CRED_INITIAL_CREDENTIALING",
+ "CRED_RECREDENTIALING",
+ "CRED_CAQH",
+ "CRED_HOSPITAL_PRIVILEGING",
+ "CRED_STATE_LICENSING",
+ "CRED_MEDICARE_MEDICAID_ENROLLMENT",
+ "CRED_DELEGATED_CREDENTIALING"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "type": "array",
+ "uniqueItems": true
+}Input schema / properties / state / descriptionPrevious value: -"Two-letter state abbreviation (e.g. 'TX', 'CA', 'NY'). Send as `state`, not `state_abbr` (`state_abbr` is an output field name only)."New value: +"Practice location as a two-letter state abbreviation (e.g. 'TX', 'CA', 'NY'). Required unless vendor_geo_preference is NATIONAL_OK or NATIONAL_ONLY. Send as `state`, not `state_abbr` (`state_abbr` is an output field name only)."Input schema / properties / vendor_geo_preferenceAdded value: +{
+ "description": "Vendor geography preference, separate from practice location: LOCAL_PREFERRED prefers same-city vendors, STATE_PREFERRED prefers in-state vendors, NATIONAL_OK allows national vendors to compete across geography tiers, and NATIONAL_ONLY restricts eligibility to national or explicitly serves-your-state vendors. State may be omitted for NATIONAL_OK or NATIONAL_ONLY.",
+ "enum": [
+ "LOCAL_PREFERRED",
+ "STATE_PREFERRED",
+ "NATIONAL_OK",
+ "NATIONAL_ONLY"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "category",
- "state"
-]New value: +[
+ "category"
+]search_providers1 field changedInput schema / properties / city / descriptionPrevious value: -"City name to filter by (partial match supported)"New value: +"City to filter by. Matches one exact city only: the value is compared as a city slug (case and punctuation ignored, e.g. 'San Antonio' matches 'san-antonio'); partial names and prefixes do not match."search_providers2 fields changedInput schema / properties / practice_size_fit / descriptionPrevious value: -"Filter providers by the practice size they best serve."New value: +"Filter providers by the practice size they best serve, on the directory's one closed vocabulary: Solo, Small, Mid-size, Large, All. The filter reads the extracted size where one exists and the listing's stated fit otherwise; a listing stating 'Solo/Small' answers both Solo and Small. 'All' means the vendor serves every size -- on listings that were never extracted it is also the default, so it narrows results little."Input schema / properties / practice_size_fit / enumPrevious value: -[
- "Solo/Small",
- "Mid-size",
- "Large",
- "All"
-]New value: +[
+ "Solo",
+ "Small",
+ "Mid-size",
+ "Large",
+ "All"
+]search_providers1 field changedInput schema / properties / min_rating / descriptionPrevious value: -"Minimum quality score (0-100). Most providers score 50-85. The parameter is named `min_rating`, not `min_quality_score`."New value: +"Minimum profile-completeness score (0-100; how many listing fields are filled in, not a quality or reputation rating). Most providers score 50-85. The parameter is named `min_rating`, not `min_quality_score`."list_categoriesmatch_practice4 fields changedInput schema / properties / category / descriptionPrevious value: -"Service category needed (e.g. 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Software')"New value: +"Service category needed. One of the 25 categories: 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Consulting', 'Healthcare Legal Services', 'Healthcare CPA & Tax Advisory', 'Medical Coding Services', 'Healthcare Staffing & Recruiting', 'Healthcare Marketing & Reputation Management', 'Compliance & HIPAA Services', 'Medical Equipment & Supplies', 'Healthcare Real Estate & Site Selection', 'Practice Financing & Loans', 'Healthcare Construction & Facilities', 'Healthcare Signage & Wayfinding', 'Medical Waste & Environmental Services', 'Healthcare Insurance & Malpractice Brokers', 'Practice Valuation & Brokerage', 'Patient Financing & Payment Solutions', 'Medical Transcription & Documentation', 'Pharmacy & Medication Management', 'Telehealth & Virtual Care Infrastructure', 'Laboratory & Diagnostics Services', 'Group Purchasing Organizations (GPOs)', 'Healthcare PR & Communications'. Common aliases also resolve (e.g. 'billing', 'RCM', 'EHR', 'credentialing'). Call list_categories for the live list with provider counts."Input schema / properties / city / descriptionPrevious value: -"City where the practice is located"New value: +"City where the practice is located. Send city and state separately, not as a combined `location` string."Input schema / properties / practice_size / descriptionPrevious value: -"Size of the practice by provider count"New value: +"Size of the practice by provider count. The parameter is named `practice_size`, not `size`."Input schema / properties / state / descriptionPrevious value: -"Two-letter state abbreviation (e.g. 'TX', 'CA', 'NY')"New value: +"Two-letter state abbreviation (e.g. 'TX', 'CA', 'NY'). Send as `state`, not `state_abbr` (`state_abbr` is an output field name only)."search_providers3 fields changedInput schema / properties / category / descriptionPrevious value: -"Service category to search (e.g. 'Medical Billing & RCM', 'Credentialing Services')"New value: +"Service category to search. One of the 25 categories: 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Consulting', 'Healthcare Legal Services', 'Healthcare CPA & Tax Advisory', 'Medical Coding Services', 'Healthcare Staffing & Recruiting', 'Healthcare Marketing & Reputation Management', 'Compliance & HIPAA Services', 'Medical Equipment & Supplies', 'Healthcare Real Estate & Site Selection', 'Practice Financing & Loans', 'Healthcare Construction & Facilities', 'Healthcare Signage & Wayfinding', 'Medical Waste & Environmental Services', 'Healthcare Insurance & Malpractice Brokers', 'Practice Valuation & Brokerage', 'Patient Financing & Payment Solutions', 'Medical Transcription & Documentation', 'Pharmacy & Medication Management', 'Telehealth & Virtual Care Infrastructure', 'Laboratory & Diagnostics Services', 'Group Purchasing Organizations (GPOs)', 'Healthcare PR & Communications'. Common aliases also resolve (e.g. 'billing', 'RCM', 'EHR', 'credentialing'). Call list_categories for the live list with provider counts. This tool does NOT accept a specialty filter -- use match_practice for specialty-aware ranking."Input schema / properties / min_rating / descriptionPrevious value: -"Minimum quality score (0-100). Most providers score 50-85."New value: +"Minimum quality score (0-100). Most providers score 50-85. The parameter is named `min_rating`, not `min_quality_score`."Input schema / properties / state / descriptionPrevious value: -"Two-letter state abbreviation (e.g. 'TX'). National providers always included."New value: +"Two-letter state abbreviation (e.g. 'TX'). Send as `state`, not `state_abbr` (`state_abbr` is an output field name only). National providers always included."get_provider_detail1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "const": "text"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "const": 1,
+ "description": "Always 1 on success; absent when isError."
+ },
+ "ids": {
+ "description": "Absent when isError.",
+ "properties": {
+ "drilled": {
+ "description": "The slug that was looked up.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "isError": {
+ "description": "Present and true only when the slug is unknown or the fetch fails.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "content"
+ ],
+ "type": "object"
+}match_practice1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "const": "text"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "description": "Total scored candidates before the top-5 slice; absent when isError.",
+ "type": "integer"
+ },
+ "ids": {
+ "description": "Absent when isError.",
+ "properties": {
+ "surfaced": {
+ "description": "Provider slugs shown, in ranked order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "isError": {
+ "description": "Present and true only on failure (match request error or no candidates).",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "content"
+ ],
+ "type": "object"
+}search_providers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "content": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "const": "text"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "description": "Total matching providers across all pages; absent when isError.",
+ "type": "integer"
+ },
+ "ids": {
+ "description": "Absent when isError.",
+ "properties": {
+ "surfaced": {
+ "description": "Provider slugs on this page, in returned order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "isError": {
+ "description": "Present and true only on failure.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "content"
+ ],
+ "type": "object"
+}search_providers4 fields changedInput schema / properties / per_page / descriptionPrevious value: -"Results per page (1-50, default 10)"New value: +"Results per page (1-25, default 10)"Input schema / properties / per_page / maximumPrevious value: -50New value: +25Input schema / properties / practice_size_fitAdded value: +{
+ "description": "Filter providers by the practice size they best serve.",
+ "enum": [
+ "Solo/Small",
+ "Mid-size",
+ "Large",
+ "All"
+ ],
+ "type": "string"
+}Input schema / properties / tier1_gradeAdded value: +{
+ "description": "Filter to the curated Tier-1 provider set by grade: 'A' (top-graded) or 'B' (strong). Tier-1 is a hand-reviewed ~4,400-provider subset; most directory records are not Tier-1, so this narrows results sharply. Omit to search the full directory.",
+ "enum": [
+ "A",
+ "B"
+ ],
+ "type": "string"
+}get_provider_detail1 field changedInput schema / properties / slug / descriptionPrevious value: -"Provider slug identifier (e.g. 'ams-solutions-inc-dallas-tx')"New value: +"Provider slug identifier (e.g. 'ams-solutions-inc-dallas-tx'). Obtained from match_practice or search_providers response."match_practice5 fields changedInput schema / properties / budget_range / descriptionPrevious value: -"Monthly budget range"New value: +"Approximate monthly budget"Input schema / properties / category / descriptionPrevious value: -"Service category needed (e.g. 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR')"New value: +"Service category needed (e.g. 'Medical Billing & RCM', 'Credentialing Services', 'Healthcare IT & EHR', 'Practice Management Software')"Input schema / properties / ehr_system / descriptionPrevious value: -"EHR system used by the practice (e.g. 'Epic', 'athenahealth', 'AdvancedMD')"New value: +"EHR system used by the practice (e.g. 'Epic', 'athenahealth', 'AdvancedMD', 'eClinicalWorks'). Helps score providers with compatible integrations higher."Input schema / properties / practice_size / descriptionPrevious value: -"Size of the practice"New value: +"Size of the practice by provider count"Input schema / properties / specialty / descriptionPrevious value: -"Medical specialty of the practice (e.g. 'Family Medicine', 'Cardiology', 'Pediatrics')"New value: +"Medical specialty of the practice (e.g. 'Family Medicine', 'Cardiology', 'Pediatrics', 'Dermatology')"search_providers12 fields changedInput schema / properties / category / descriptionPrevious value: -"Service category to search (e.g. 'Medical Billing & RCM')"New value: +"Service category to search (e.g. 'Medical Billing & RCM', 'Credentialing Services')"Input schema / properties / city / descriptionPrevious value: -"City name to filter by"New value: +"City name to filter by (partial match supported)"Input schema / properties / min_rating / descriptionPrevious value: -"Minimum quality score (0-100)"New value: +"Minimum quality score (0-100). Most providers score 50-85."Input schema / properties / min_rating / maximumAdded value: +100Input schema / properties / min_rating / minimumAdded value: +0Input schema / properties / page / defaultAdded value: +1Input schema / properties / page / minimumAdded value: +1Input schema / properties / per_page / defaultAdded value: +10Input schema / properties / per_page / descriptionPrevious value: -"Number of results to return (default 10, max 50)"New value: +"Results per page (1-50, default 10)"Input schema / properties / per_page / maximumAdded value: +50Input schema / properties / per_page / minimumAdded value: +1Input schema / properties / state / descriptionPrevious value: -"Two-letter state abbreviation"New value: +"Two-letter state abbreviation (e.g. 'TX'). National providers always included."get_provider_detailmatch_practicesearch_providersCMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
Search 7,000+ local service businesses across America by category, location, or keyword.
Find US healthcare providers by name, specialty, location or NPI from the CMS NPPES registry.
US health care providers by NPI, name or phone, with payments, Medicare, OIG and facility data.
Add one secure layer between your agents and this server.
