Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

healthgrades_physicians_search

Search Healthgrades physicians by specialty, condition, procedure, or name near a location. Returns NPI, specialty, ratings, insurers, profile links, and available filters.

Instructions

Search Healthgrades physicians. Returns one page of Healthgrades provider search results for a specialty, condition, procedure, or provider name near a location, with each provider's NPI, specialty, office, aggregate patient rating, accepted insurers, and profile URL, plus the filters available for the search. Closed-set filters accept the listed values; insurance, insurance_plan, language, clinical_focus, affiliated_hospital, and specialty accept values returned in the filters for the same query/where. List filters take comma-separated values. Requests use US egress because Healthgrades restricts content by region. Patient review text is not returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNoComma-separated provider age bands
pageNoResult page (1-500, 20 results per page)
sortNoResult order
queryYesSpecialty, condition, procedure, or provider name
whereNoCity and state, or ZIP code
genderNoProvider gender
ratingNoMinimum patient-satisfaction stars (5 means exactly 5)
distanceNoSearch radius in miles
languageNoComma-separated language codes from the language filter
insuranceNoComma-separated insurer codes from the insurance filter
specialtyNoComma-separated practicing-specialty codes from the specialty filter
availabilityNoComma-separated availability filters
affirming_careNoOnly providers marked LGBTQ+ affirming
clinical_focusNoComma-separated clinical focus codes from the clinical_focus filter
insurance_planNoComma-separated plan IDs from an insurer's plans (requires insurance)
affiliated_hospitalNoComma-separated hospital codes from the affiliated_hospital filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that results are a single paginated page, that review text is not returned, that content is US-region-restricted (requiring US egress), and how filter value domains are resolved from a companion filters call. It stops short of noting rate limits or auth requirements, but the behavioral surface is well covered.

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

Conciseness4/5

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

Front-loaded with purpose and return shape, then filter mechanics, then the regional constraint and the explicit return exclusion. Every sentence carries information, though the single dense paragraph is slightly heavy and could be broken up for faster scanning.

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

Completeness5/5

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

For a 16-parameter search with no output schema, the description compensates precisely: it enumerates returned fields and states what is not returned, so an agent does not need an output schema to interpret results. Combined with region and filter-domain notes, nothing material is missing.

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

Parameters4/5

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 meaning beyond the schema: it distinguishes closed-set enums from dynamic filter-derived fields, specifies comma-separated list syntax, and flags that insurance_plan requires insurance. This is value a caller would not get from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search Healthgrades physicians') and immediately enumerates the returned fields (NPI, specialty, office, rating, insurers, profile URL), which cleanly distinguishes it from the single-entity sibling healthgrades_physician and the filter-only sibling healthgrades_physicians_filters. An agent can tell what this does 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives solid operational guidance on filter behavior (closed-set vs filter-derived values, comma-separated lists, the insurance→insurance_plan dependency), which is implied usage help. However, it never states when to prefer this search over the single-physician or physicians-filters siblings, nor any exclusion conditions, so no explicit alternative routing is provided.

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

Deploy Server

Other Tools