Find 76,000+ curated healthcare service vendors across 25 categories and all 50 US states.
Scored across 4 tools
Each tool has a distinct role: list_categories enumerates the directory taxonomy, search_providers is open-ended browsing/filtering, match_practice returns ranked recommendations for a specific practice profile, and get_provider_detail fetches one vendor's full profile. The overlap between search and match is explicitly addressed in their descriptions, making misselection unlikely.
All tool names follow a consistent verb_noun snake_case pattern: list_categories, search_providers, match_practice, get_provider_detail. The naming style is uniform and intuitive, with verbs accurately reflecting the action.
Four tools is a well-scoped size for a read-only directory finder: discover categories, browse/search, match to a practice, and retrieve details. Each tool serves a distinct step in the user journey without redundancy or bloat.
The toolset covers the full exploration-to-selection flow: list_categories for discovery, search_providers for filtering, match_practice for personalized recommendations, and get_provider_detail for deep-dive information. For a read-only lookup service, there are no notable gaps or dead ends.
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", "is [vendor] verified", 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), verified status, description, services offered, practice_size_fit, phone and website where listed, Google rating and Google review count where present, and the profile URL. 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?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: quality_score is 'profile completeness, not a quality rating', unknown slugs return an error, and enrichment-extracted results carry confidence and grounding information. It also clarifies how legacy vs extracted fields are labeled, which is valuable behavioral 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?
All content is relevant and the description is front-loaded with purpose and usage. However, the enrichment condition is a long, dense run-on sentence that could be split for easier parsing, preventing a 5.
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 fully covers the tool's pipeline position, expected input provenance, output fields, conditional behavior, and error handling. Given the output schema and read-only annotations, nothing essential is missing for correct invocation.
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 baseline is 3. The description mostly restates that the slug comes from match_practice or search_providers and adds an error condition, but it does not meaningfully extend the schema's parameter documentation.
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 a specific verb and resource: 'Get the full profile of one healthcare vendor by slug.' It clearly differentiates from siblings by framing the tool as the detail-retrieval step after match_practice or search_providers, not a listing or search operation.
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 explicit when-to-use guidance: 'Use this after match_practice or search_providers when the user asks to tell me more about [vendor]' and lists concrete user intents. It also implicitly excludes sibling tools by positioning this as the follow-up detail lookup, making the selection decision clear.
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), verified status, description, website, profile_url, slug}. 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 | Yes | Two-letter state abbreviation (e.g. 'TX', 'CA', 'NY'). 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`. |
| 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 establish read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond them: result cap (up to 5), merit-ranking with no paid placement, the meaning of final_score, and the crucial clarification that quality_score is profile completeness rather than reputation, including the 0-means-never-scored edge case.
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 then usage then mechanics; the example phrase list and the full output-field enumeration are longer than strictly necessary, but every element is informative and no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter scored-matching tool with an output schema present, the description covers invocation conditions, scoring semantics, result limits, and handoff to sibling tools. An agent has everything needed to call and interpret it.
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% and the schema already carries naming warnings, aliases, and the category list, so the baseline is 3. The description adds value by explaining how the profile parameters (specialty, size, location, EHR system, budget) are consumed for scoring, which the schema does not state.
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 ('Recommend and rank the best healthcare vendors for a specific medical practice') and immediately distinguishes itself from siblings by routing open-ended browsing to search_providers and full profiles to get_provider_detail. The scope (practice-profile-driven matching) is unmistakable.
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 when-to-use with four concrete example phrasings, plus an explicit when-not ('For open-ended browsing without a practice profile, use search_providers') and a follow-up path ('Pass a match's slug to get_provider_detail'). Nothing is left to inference.
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), verified status, 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 mark the operation read-only, idempotent, and non-destructive; the description adds substantive behavior beyond that: pagination, the meaning of quality_score as profile completeness rather than quality, 0 meaning never scored, national providers always being included, and the sharp narrowing effect of Tier-1 filtering. These are non-obvious, decision-relevant behaviors an agent needs before calling.
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 front-loaded with the core verb phrase and keeps examples, output-shape, and routing notes in compact clauses. Every sentence contributes either usage guidance, filter/return semantics, or sibling differentiation; there is 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?
With an output schema present, the description did not need to enumerate return values, yet it still names the returned fields and clarifies the ambiguous quality_score field. Combined with the detailed parameter descriptions and annotations, an agent has everything needed to call search_providers correctly, including pagination and the distinction from match_practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents each parameter in detail, including city slug matching, state vs state_abbr, category aliases, min_rating semantics, and the practice_size vocabulary. The prose description only names the filter categories at a high level and does not add new parameter-level meaning, so it stays at the baseline for high schema coverage.
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 text opens with 'Browse and filter the healthcare vendor directory,' naming a concrete verb, object, and intent. It also preempts confusion with sibling tools by explicitly separating open-ended exploration and paging from a scored shortlist, and it points to match_practice and get_provider_detail for adjacent tasks.
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 states explicitly when to use this tool ('open-ended exploration', 'page through options rather than get a scored shortlist') and when to use an alternative ('For a scored recommendation to a specific practice profile, use match_practice instead'). It also closes the loop by instructing the agent to pass a returned slug to get_provider_detail for full profiles.
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.
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.
Research 7,400+ US doctors: search, semantic search, profiles, reviews & procedure pricing.
Healthcare provider & compliance intel: NPPES lookup, OIG/SAM exclusion screening, FDA enforcement.
Add one secure layer between your agents and this server.
