VetClinic.info — Veterinary Specialty Directory

search_clinics

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.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	Yes	City slug (e.g. "denver", "austin", "new-york"). Display names ("Denver", "New York") are accepted and normalised.
`limit`	No
`state`	No	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.
`specialty`	Yes	Specialty 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.

All VetClinic.info — Veterinary Specialty Directory tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

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.

Resources

Need Help?