Loading ToolBench
MCP server for xcircl regulated-care provider data API. Exposes three tools (search_providers, get_provider, check_compliance) to search verified U.S. healthcare providers, retrieve individual provider records, and check compliance signals (LegitScript, state licenses, FDA screens). Requires XCIRCL_API_KEY; free keys return identity fields, paid plans unlock compliance and pricing data.
Three tools with complete schemas, strong descriptions (194 - 250 chars), and clear parameter types. All parameters have descriptions and constraints (enums, min/max). Tool names follow verb_noun pattern (search_, get_, check_). Output schemas documented in descriptions. Key gaps: no error handling guidance (e.g., 'if not found, try search_providers'), no confirmation pattern for compliance-gated features, and parameter descriptions could better explain when to use each tool vs. alternatives. Naming is clear but could distinguish search_providers (multi-result) from get_provider (single) more explicitly in descriptions.
Compliance signals for one provider: LegitScript certification, state-license record, FDA warning-letter screen — each with status, source and verification timestamp. These are plan-gated fields. A free XCIRCL_API_KEY returns provider identity + compliance: null and explains how to unlock them: "Full fields (cash_price, compliance) require paid access → https://xcircl.com/pricing/". Signal statuses: verified (source+date held) | clear (negative screen run) | flagged (adverse finding) | reported (self-reported) | unverified | not_screened. Returns JSON: { entity_id, slug, name, tier, compliance: { legitscript, license, fda } | null, notice? }.
Fetch a single provider by entity_id (e.g. "ent_f47550b79f755d70b58b183a") or slug (e.g. "alegro-health-mckinney-tx"). A free XCIRCL_API_KEY returns identity fields + notice. Keys with compliance access return legitscript / license / fda signals and price, each source-linked and timestamped. Returns JSON: { tier, publish_boundary, notice?, data: Provider }. Errors with a clear message if the id is unknown.
Search verified U.S. regulated-care providers (currently the GLP-1 / weight-management vertical is live) by vertical, city, state and business mode. A free XCIRCL_API_KEY returns identity fields per provider — entity_id, slug, vertical, name, city, state, business_mode, latitude, longitude, npi — plus a notice describing plan-gated fields. Keys with compliance access add legitscript / license / fda signals and cash price, each with source + verification timestamp. Returns JSON: { tier, publish_boundary, notice?, pagination: { total, limit, offset, returned }, filters, data: Provider[] }. Examples: - "GLP-1 clinics in Austin" → { vertical: "glp1", city: "Austin", state: "TX" } - "online GLP-1 providers" → { vertical: "glp1", business_mode: "online" } Use get_provider for one record, check_compliance for compliance signals only.
No error recovery guidance. Descriptions do not explain what to do if a provider is not found or if compliance data is unavailable. LLMs need explicit next steps (e.g., 'If not found, try search_providers with broader filters').
Parameter descriptions lack actionable constraints. 'city' and 'state' descriptions do not specify case-sensitivity, required format, or validation rules. 'limit' description omits why the 1 - 100 range exists (API constraint vs. performance).
Tool selection ambiguity. Descriptions do not clearly explain when to call search_providers (discovery) vs. get_provider (known ID) vs. check_compliance (compliance-only). LLMs may waste calls trying all three.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Compliance gating not surfaced in tool descriptions. check_compliance requires a paid plan, but the description does not warn the LLM or suggest fallback behavior. Users with free keys will see null compliance and no guidance on how to unlock it.
Output schema documentation incomplete. Descriptions mention return structure (e.g., 'Returns JSON: { tier, publish_boundary, ... }') but do not document field types, nullability, or what each field means. LLMs cannot reliably extract or chain results.