Skip to main content
Glama

VetClinic.info — Veterinary Specialty Directory

by info.vetclinic
OverviewDiscussionsAdmin

Server Details

Find US veterinary specialists. Search clinics, read procedure articles, estimate costs.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
98.0% over 57 days
Last Tested
Transport
Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation4/5

Most tools are clearly distinct, but estimate_procedure_cost and quote_for_case overlap significantly (quote_for_case without PII behaves identically to estimate_procedure_cost). Also, find_specialists_by_procedure duplicates the clinic-finder portion of get_procedure when state is supplied, though descriptions clarify the different focus.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (list, get, search, estimate, quote, find). The naming is predictable and clearly indicates the action and target resource.

Tool Count5/5

Eight tools is well within the ideal range for a directory service. Each tool serves a distinct purpose related to browsing procedures, specialties, clinics, or generating estimates, with no obvious bloat or redundancy.

Completeness4/5

The tool surface covers the core directory workflows: listing/retrieving procedures and specialties, searching clinics, fetching clinic details, and estimating costs. Minor gaps include lack of a direct 'list clinics by specialty' tool and no way to manage or update directory entries, but these are not critical for a read-only directory.

Available Tools

8 tools
estimate_procedure_costInspect

Anonymous cost estimate. Returns $low–$high range computed from regional + case factors. Only procedure_slug is required: anything omitted gets a stated default listed in "assumptions" (no zip → the state, else the national range). Deterministic on identical inputs. PII fields are rejected — use quote_for_case for the PII path.

ParametersJSON Schema
NameRequiredDescriptionDefault
zipNoUS ZIP (5-digit or ZIP+4). Optional.
cityNoCity slug. Optional.
stateNoUS state code or name. Optional; used for the regional adjustment when there is no zip.
case_factorsNoAll optional. Defaults (stated in the result): dog, m, adult, moderate, elective. Plain words and numbers are understood.
procedure_slugYesFrom list_procedures, e.g. tplo-surgery.
find_specialists_by_procedureAInspect

Convenience: combines get_procedure + state filter. Returns the ranked specialist finder list for a procedure in a given state.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
stateYes2-letter state slug.
procedureYesProcedure slug.

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns a ranked list and is a convenience wrapper, which implies a read-only operation. However, it does not explicitly state that it has no side effects, nor does it mention pagination or other behavioral details that could be relevant.

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

Conciseness5/5

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

The description is two concise sentences with no unnecessary words. It front-loads the key concept ('Convenience') and immediately explains the tool's behavior, making it easy to scan.

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

Completeness4/5

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

Given the simple schema (3 params, no output schema) and the presence of sibling tools, the description adequately explains the tool's purpose and relationship to get_procedure. It does not cover the limit parameter's behavior or return format, but those are inferable from the schema and the 'list' wording.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (procedure and state have descriptions; limit does not). The description adds only marginal value by clarifying that the result is filtered by state, but it does not elaborate on the 'slug' format or explain the limit parameter beyond what the schema already provides.

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?

The description clearly states the tool's function: it combines get_procedure with a state filter and returns a ranked specialist finder list. This specific verb ('Returns') and resource ('ranked specialist finder list') clearly distinguish it from sibling tools like get_procedure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The 'Convenience' framing implies this tool should be used when you need both a procedure lookup and a state filter together, rather than calling get_procedure separately. However, it does not explicitly state when not to use this tool or mention alternative approaches, leaving some room for interpretation.

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

get_clinicAInspect

Fetch a single clinic's full record by slug: credentials, inline reviews, procedures performed, contact action, canonical URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYesCity slug.
slugYesClinic slug. Clinic slugs are unique per city, not globally — pair with city + state for disambiguation.
stateYesState slug.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses the return contents ('credentials, inline reviews, procedures performed, contact action, canonical URL'), which is useful, but it does not explicitly state read-only behavior, error handling, authentication requirements, or any side effects. It is a mild positive but not a 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.

Conciseness5/5

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

The description is a single, front-loaded sentence that immediately states the action and resource, followed by a concise list of contents. Every word earns its place; no filler or repetition.

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

Completeness4/5

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

For a simple fetch tool with 100% schema coverage and no output schema, the description adequately covers what the tool does and what it returns. It could explicitly mention error behavior or fallbacks, but given the tool's simplicity, the current description is sufficiently complete.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already has 100% coverage, with each parameter described and the slug explanation calling out that slugs are unique per city. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description uses a specific verb ('Fetch') and resource ('a single clinic's full record'), clearly distinguishing it from sibling tools like search_clinics (which searches) and get_procedure (which fetches a procedure). It also enumerates the record's contents (credentials, reviews, procedures, contact action, canonical URL), making the purpose unmistakable.

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 implies the tool is for fetching a single clinic when you know its slug, but it does not explicitly state when to use this over alternatives like search_clinics, nor does it mention exclusions or prerequisites. The schema provides helpful disambiguation guidance (pairing slug with city and state), but the description itself lacks direct usage direction.

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

get_procedureAInspect

Fetch a procedure article with cost band, contraindications, emergency signals, FAQ, citations. When state is supplied, also returns a ranked clinic finder pre-filtered to that state.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesProcedure slug (e.g. "tplo", "hemilaminectomy", "lymphoma-chop").
stateNoOptional 2-letter state slug to pre-filter the finder.

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses conditional behavior (state triggers a clinic finder) and the article's contents. However, it does not explicitly state whether the tool is read-only, error behavior, or any limitations. Adequate but not rich.

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

Conciseness5/5

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

Two sentences, front-loaded with the main purpose. Every part is meaningful, no fluff. Excellent structure.

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

Completeness4/5

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

For a relatively simple fetch tool with two parameters, the description is complete enough: it lists the article sections and the conditional clinic finder. Minor gaps include error handling and invalid input behavior, but these are not critical for a read-only retrieval tool.

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% for both parameters. The description adds meaning by explaining that providing state triggers an additional 'ranked clinic finder' sub-component, which is not fully conveyed by the schema's 'pre-filter the finder.' This adds semantic value beyond the schema.

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?

The description clearly identifies the tool's purpose: fetching a procedure article with specific sections (cost band, contraindications, emergency signals, FAQ, citations). It distinguishes itself from sibling tools like estimate_procedure_cost, get_clinic, and find_specialists_by_procedure by focusing on the article retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description implies usage context: use when you need a procedure article. It mentions conditional behavior with state (clinic finder) but does not explicitly state when not to use it or mention alternatives like search_clinics. Clear context, but no exclusions.

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

list_proceduresAInspect

Published procedure catalog. Returns slug, display_name, also_known_as, specialty_slug for every procedure with a live article.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/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 behavioral burden. It discloses the live-article filter and the exact returned fields, which adds meaningful context beyond a generic 'list procedures'. It does not mention pagination, ordering, or explicit read-only status, but for a no-parameter list tool the behavior is clear and non-destructive.

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

Conciseness5/5

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

The description is a single sentence that leads with the core concept ('Published procedure catalog') followed by the specific return fields and filtering condition. Every word earns its place with no redundancy or filler.

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 simple list tool with no parameters and no output schema, the description is complete. It specifies the scope (published, live articles), the exact fields returned, and the coverage ('every procedure'). It provides all necessary information for an agent to invoke the tool and interpret results.

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?

The tool has zero parameters, so the description rightly focuses on output semantics. Baseline for zero-parameter tools is 4. No parameter explanations are needed, and the schema (empty) confirms no inputs.

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?

The description clearly states the tool returns a published procedure catalog with specific fields (slug, display_name, also_known_as, specialty_slug) for every procedure with a live article. This is a specific verb+resource combination that is distinct from siblings like get_procedure (single procedure) and list_specialties (specialties).

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 implies the tool is for listing all procedures but doesn't explicitly compare to alternatives like get_procedure or search_clinics. It provides context (published catalog, live articles) but lacks explicit when-to-use or when-not-to-use guidance. Usage is implied rather than stated.

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

list_specialtiesAInspect

Closed-set enum of recognized veterinary specialty slugs. Returns slug, display_name, and credentialing_board.sameAs (when applicable). Always call this before search_clinics if uncertain about specialty mapping.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden and largely meets it by describing output fields and the 'when applicable' qualifier for sameAs. It implies a read-only operation via 'Returns' and defines the scope as a 'closed-set enum', but it does not explicitly confirm no side effects or other behavioral details.

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

Conciseness5/5

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

Two sentences: the first defines the tool's essence and return structure; the second gives actionable usage context. Every phrase earns its place with no padding or redundancy.

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 no-parameter, no-output-schema tool, the description fully covers what the tool returns, the nature of the data ('closed-set enum'), and when to invoke it. It is self-sufficient and leaves no major gaps for an agent to misuse.

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?

The tool has zero parameters, so by the rubric baseline is 4. The description adds no parameter explanation because none are needed.

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?

The description states a specific verb ('Returns') and resource ('specialty slugs'), clearly identifying it as a reference list tool. It distinguishes itself from search_clinics by framing itself as a prerequisite mapping step, and it enumerates exact return fields (slug, display_name, credentialing_board.sameAs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Provides explicit guidance: 'Always call this before search_clinics if uncertain about specialty mapping.' This gives a clear when-to-use scenario, though it does not mention alternatives beyond search_clinics or explicitly 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.

quote_for_caseInspect

Composite tool. Always computes an estimate. When owner_email is also present, the case is accepted on arrival: routed at once to a board-certified specialist near the owner (or held while we match one), and the owner gets a receipt email. Requires X-Agent-Attribution when PII is supplied. When PII is absent, behaves identically to estimate_procedure_cost and returns status="estimate_only".

ParametersJSON Schema
NameRequiredDescriptionDefault
zipNoUS ZIP. Optional.
cityNoCity slug. Optional; helps route to a practice near the owner.
stateNoUS state code or name. Optional.
case_notesNoOptional. Free-text notes from the owner for the receiving clinic.
owner_nameNoOptional. The email's local part is used if omitted.
owner_emailNoOptional. When present, submits the quote request (accepted on arrival) and requires X-Agent-Attribution.
owner_phoneNoOptional.
case_factorsNoSame shape as estimate_procedure_cost.case_factors. Optional.
procedure_slugYes
search_clinicsAInspect

Find veterinary specialty clinics by city + specialty. Returns a ranked shortlist with credentials, address, rating, review count, and a contact action. Promoted listings rank first. state is genuinely optional: omit it and the city is resolved across states; if that city slug exists in more than one state the error carries a data.candidates array (state, state_name, clinic_count) to re-call with.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYesCity slug (e.g. "denver", "austin", "new-york"). Display names ("Denver", "New York") are accepted and normalised.
limitNo
stateNoOptional 2-letter state slug ("co", "tx", "ca"). Omit it unless you know it — it is only needed to disambiguate a city slug shared by several states, and the error response tells you when that happens.
specialtyYesSpecialty slug (e.g. "orthopedic-surgery", "oncology", "emergency-critical-care", "generalist"). Closed set; use list_specialties.

TDQS

A4/5.0
Behavior4/5

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

No annotations exist, so the description carries the burden; it discloses ranking behavior (promoted list first), return fields, and the disambiguation error with data.candidates, but omits auth/rate limits and pagination details.

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

Conciseness5/5

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

Four concise sentences front-load the purpose and key behaviors with zero filler.

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

Completeness4/5

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

For a search tool with no output schema, it adequately describes return shape and the ambiguity error pathway, though it lacks notes on pagination or auth requirements.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already covers 75% of params with descriptions; the description adds value by explaining the genuinely-optional state behavior and the error-response re-call nuance, but doesn't fully clarify limit semantics beyond schema.

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?

Clearly states it finds veterinary specialty clinics by city+specialty, lists return fields (credentials, address, rating, review count, contact action), and distinguishes from sibling tools like get_clinic (single clinic) and find_specialists_by_procedure (by procedure).

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?

Provides clear search context (city+specialty) and advises how to handle optional state, but doesn't explicitly name alternatives or when-not-to-use scenarios relative to sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedestimate_procedure_cost30 fields changed
      • removedInput schema / properties / case_factors / additionalProperties
        Removed value: -false
      • addedInput schema / properties / case_factors / description
        Added value: +"All optional. Defaults (stated in the result): dog, m, adult, moderate, elective. Plain words and numbers are understood."
      • addedInput schema / properties / case_factors / properties / age_band / description
        Added value: +"puppy, young-adult, adult or senior."
      • removedInput schema / properties / case_factors / properties / age_band / enum
        Removed value: -[
-  "puppy",
-  "young-adult",
-  "adult",
-  "senior"
-]
      • addedInput schema / properties / case_factors / properties / age_band / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / age_years
        Added value: +{
+  "type": "number"
+}
      • addedInput schema / properties / case_factors / properties / comorbidities / description
        Added value: +"cardiac, renal, endocrine, obesity."
      • removedInput schema / properties / case_factors / properties / comorbidities / items / enum
        Removed value: -[
-  "cardiac",
-  "renal",
-  "endocrine",
-  "obesity"
-]
      • addedInput schema / properties / case_factors / properties / comorbidities / items / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / severity / description
        Added value: +"mild, moderate or severe."
      • removedInput schema / properties / case_factors / properties / severity / enum
        Removed value: -[
-  "mild",
-  "moderate",
-  "severe"
-]
      • addedInput schema / properties / case_factors / properties / severity / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / species / description
        Added value: +"dog or cat (canine/feline understood)."
      • removedInput schema / properties / case_factors / properties / species / enum
        Removed value: -[
-  "dog",
-  "cat"
-]
      • addedInput schema / properties / case_factors / properties / species / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / urgency / description
        Added value: +"elective, urgent or emergency."
      • removedInput schema / properties / case_factors / properties / urgency / enum
        Removed value: -[
-  "elective",
-  "urgent",
-  "emergency"
-]
      • addedInput schema / properties / case_factors / properties / urgency / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / weight_band / description
        Added value: +"xs <5 kg · s 5–15 · m 15–30 · l 30–50 · xl >50."
      • removedInput schema / properties / case_factors / properties / weight_band / enum
        Removed value: -[
-  "xs",
-  "s",
-  "m",
-  "l",
-  "xl"
-]
      • addedInput schema / properties / case_factors / properties / weight_band / type
        Added value: +"string"
      • addedInput schema / properties / case_factors / properties / weight_kg
        Added value: +{
+  "type": "number"
+}
      • addedInput schema / properties / case_factors / properties / weight_lb
        Added value: +{
+  "type": "number"
+}
      • removedInput schema / properties / case_factors / required
        Removed value: -[
-  "species",
-  "weight_band",
-  "age_band",
-  "severity",
-  "urgency"
-]
      • addedInput schema / properties / city
        Added value: +{
+  "description": "City slug. Optional.",
+  "type": "string"
+}
      • addedInput schema / properties / procedure_slug / description
        Added value: +"From list_procedures, e.g. tplo-surgery."
      • addedInput schema / properties / state
        Added value: +{
+  "description": "US state code or name. Optional; used for the regional adjustment when there is no zip.",
+  "type": "string"
+}
      • addedInput schema / properties / zip / description
        Added value: +"US ZIP (5-digit or ZIP+4). Optional."
      • removedInput schema / properties / zip / pattern
        Removed value: -"^[0-9]{5}$"
      • changedInput schema / required
        Previous value: -[
-  "procedure_slug",
-  "zip",
-  "case_factors"
-]New value: +[
+  "procedure_slug"
+]
    • Changedquote_for_case8 fields changed
      • changedInput schema / properties / case_factors / description
        Previous value: -"Same shape as estimate_procedure_cost.case_factors."New value: +"Same shape as estimate_procedure_cost.case_factors. Optional."
      • addedInput schema / properties / city
        Added value: +{
+  "description": "City slug. Optional; helps route to a practice near the owner.",
+  "type": "string"
+}
      • changedInput schema / properties / owner_email / description
        Previous value: -"Optional. When present, triggers the lead-capture write path and requires X-Agent-Attribution."New value: +"Optional. When present, submits the quote request (accepted on arrival) and requires X-Agent-Attribution."
      • changedInput schema / properties / owner_name / description
        Previous value: -"Optional. Required if owner_email is present."New value: +"Optional. The email's local part is used if omitted."
      • addedInput schema / properties / state
        Added value: +{
+  "description": "US state code or name. Optional.",
+  "type": "string"
+}
      • addedInput schema / properties / zip / description
        Added value: +"US ZIP. Optional."
      • removedInput schema / properties / zip / pattern
        Removed value: -"^[0-9]{5}$"
      • changedInput schema / required
        Previous value: -[
-  "procedure_slug",
-  "zip",
-  "case_factors"
-]New value: +[
+  "procedure_slug"
+]
  2. 1 tool update
    • Changedsearch_clinics2 fields changed
      • changedInput schema / properties / city / description
        Previous value: -"City slug (e.g. \"denver\", \"austin\"). Validate against /api/agents/specialties or list_specialties."New value: +"City slug (e.g. \"denver\", \"austin\", \"new-york\"). Display names (\"Denver\", \"New York\") are accepted and normalised."
      • changedInput schema / properties / state / description
        Previous value: -"Optional 2-letter state slug (\"co\", \"tx\", \"ca\"). Disambiguates same-name cities."New value: +"Optional 2-letter state slug (\"co\", \"tx\", \"ca\"). Omit it unless you know it — it is only needed to disambiguate a city slug shared by several states, and the error response tells you when that happens."
  3. 8 tool updates
    • First observedestimate_procedure_cost
    • First observedfind_specialists_by_procedure
    • First observedget_clinic
    • First observedget_procedure
    • First observedlist_procedures
    • First observedlist_specialties
    • First observedquote_for_case
    • First observedsearch_clinics

Related MCP Connectors

Related MCP Servers

  • BioVet by Bio-Vet

    BioVetofficial

    Bio-Vet
    A
    license
    Not graded
    quality
    A
    maintenance
    Veterinary clinic network in Moscow (20 clinics, open 24/7). Find a clinic with live ratings, check live prices for 900+ services, see open appointment slots, book a real visit, run a vet-approved symptom triage, check pet food safety, and query a knowledge base of 3,700+ vet-reviewed Q&As. Remote Streamable HTTP server at https://bio.vet/mcp, no auth required. Tools operate in Russian.
    MIT
  • Sage MCP Public by sageveterinary

    Sage MCP Publicofficial

    sageveterinary
    F
    license
    Not graded
    quality
    C
    maintenance
    Query Sage Veterinary Imaging's public data including website content, provider directory, pricing, and location details.
    -
  • costkits-mcp by costkits

    costkits-mcpofficial

    costkits
    A
    license
    A
    quality
    D
    maintenance
    Provides live US healthcare cost data including procedure cost estimates, provider pricing, insurance coverage rules, and medical bill analysis using real hospital transparency and CMS data.
    12
    43 npm
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources