VetClinic.info — Veterinary Specialty Directory
Server Details
Find US veterinary specialists. Search clinics, read procedure articles, estimate costs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: listing, searching, fetching, estimating, and quoting. The overlap between estimate_procedure_cost and quote_for_case is handled via description clarifying that one is for anonymous estimates and the other for PII-inclusive quotes, so no ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., list_procedures, get_clinic, search_clinics). Even compound names like find_specialists_by_procedure adhere to the convention, making the naming predictable and clear.
With 8 tools, the set is well-scoped for a veterinary directory server. It covers core operations (listings, searches, fetches, cost estimates, quotes) without excess or deficiency, fitting the typical 3-15 tool range.
The tool surface covers the full lifecycle for a directory: listing specialties and procedures, retrieving detailed information for clinics and procedures, searching by city/specialty, finding specialists by procedure, and estimating/quotes. No obvious gaps exist for read-only directory operations.
Available Tools
8 toolsestimate_procedure_costAInspect
Anonymous cost estimate. Returns $low–$high range computed from regional + case factors. Deterministic on identical inputs. PII fields are rejected — use quote_for_case for the PII path.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ||
| case_factors | Yes | ||
| procedure_slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral disclosure: it is anonymous (rejects PII), deterministic, and returns a range based on regional and case factors. While it doesn't explicitly state it is read-only, the context implies no destructive actions.
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-loading the core purpose. The second sentence packs additional info (deterministic, PII rejection, sibling reference) without unnecessary verbosity. Slight run-on in second sentence, but overall efficient.
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?
Given no output schema, the description partially explains the return value ('$low–$high range') but lacks exact output format details. It does not address error handling or edge cases. For a simple estimate tool, it covers essential context but could be more comprehensive.
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 0%, so the description must compensate. It maps 'regional' to zip and 'case factors' to the case_factors object, but does not detail individual parameters like procedure_slug or sub-fields within case_factors. The description adds high-level context but lacks specific parameter explanations.
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 it provides an anonymous cost estimate returning a low-high range, with a specific verb (estimate) and resource (procedure cost). It distinguishes from sibling tool quote_for_case by explicitly mentioning the PII path alternative.
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 directly states when not to use this tool ('PII fields are rejected — use quote_for_case for the PII path'), providing clear guidance on alternatives. It also mentions deterministic behavior, which aids in understanding appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_specialists_by_procedureAInspect
Convenience: combines get_procedure + state filter. Returns the ranked specialist finder list for a procedure in a given state.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | 2-letter state slug. | |
| procedure | Yes | Procedure slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it returns a 'ranked specialist finder list' without explaining ranking criteria, pagination, rate limits, auth, or any side effects. Minimal 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?
Two sentences, no wasted words. Front-loaded with core purpose ('Convenience: combines ...'). Every sentence adds value.
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?
3 parameters, no output schema, no annotations. Description covers basic purpose but lacks details on output format, error handling, ranking algorithm, or limit behavior. Adequate but leaves significant gaps.
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 has 67% coverage: 'procedure' and 'state' have descriptions, but 'limit' lacks description. Description adds context that parameters are slugs and that it combines two functions, but does not clarify 'limit' meaning beyond schema defaults. Baseline 3 due to moderate 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?
Description clearly states the tool combines get_procedure + state filter to return a ranked specialist finder list for a procedure and state. Distinguishes from siblings like get_procedure (procedure details) and search_clinics (clinic search).
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?
Description implies when to use (when needing specialists by procedure/state) but does not explicitly state when not to use or provide alternatives beyond the mention of combining two functions. No usage exclusion or comparison with sibling tools.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| slug | Yes | Clinic slug. Clinic slugs are unique per city, not globally — pair with city + state for disambiguation. | |
| state | Yes | State slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the full record contents (credentials, reviews, etc.), making expected behavior transparent. No claims contradict the nature of a read operation, though it doesn't mention error handling or rate limits.
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?
Single sentence, efficiently front-loads the action ('Fetch') and resource, lists key return fields without repetition. Every word earns its place.
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 fetch tool with three clear parameters and no output schema, the description is complete: it states what is returned (full record with specified components). No additional context is needed given the low complexity.
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?
Input schema has 100% description coverage; each parameter is already well-documented (slug, city, state). The description adds only that the fetch is 'by slug', which is redundant with the schema. Baseline 3 is appropriate as no added meaning.
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 clearly states 'Fetch a single clinic's full record by slug' and enumerates the returned data (credentials, reviews, procedures, contact, URL), making the purpose unambiguous. It distinguishes from siblings like search_clinics which would be used for multiple clinics.
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 clear context that this tool is for fetching a single clinic when you have the slug. However, it does not explicitly mention when not to use it (e.g., for searching or filtering) or name alternatives, though the action and scope are implied well enough.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Procedure slug (e.g. "tplo", "hemilaminectomy", "lymphoma-chop"). | |
| state | No | Optional 2-letter state slug to pre-filter the finder. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the returned fields and the conditional behavior with state, which is good. However, it does not disclose potential errors (e.g., not found) or any limitations (e.g., pagination of clinic finder results). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence lists the main content, the second explains the conditional behavior. Front-loaded and efficient.
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 tool with 2 parameters, no output schema, and no annotations, the description covers the core functionality and conditional behavior. It could be improved by specifying the return format or error handling, but the high schema coverage and clear purpose make it fairly complete.
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% with descriptions for both parameters. The description adds value beyond the schema by explaining the effect of the state parameter ('returns a ranked clinic finder pre-filtered to that state'). This helps the agent understand conditional behavior.
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 identifies the tool as fetching a procedure article with specific content (cost band, contraindications, etc.) and describes conditional behavior when state is supplied. This differentiates it from siblings like list_procedures (which lists) and get_clinic (which gets a specific clinic).
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 implies usage for fetching a single procedure article and optionally getting a clinic finder for a state. However, it does not explicitly state when to use this tool over alternatives like search_clinics or find_specialists_by_procedure, nor does it provide exclusion criteria.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool is a read-only catalog listing, and the absence of parameters confirms no side effects. It could mention ordering or pagination, but for a simple list it is adequate.
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 a single, efficient sentence that conveys all necessary information without extraneous words. It is front-loaded with the primary action (list procedures) and provides specific return fields.
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?
Given the simplicity of the tool (no parameters, no output schema), the description is complete. It specifies the return fields and the condition for inclusion (live article). No additional context is needed.
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 input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable since none exist. Baseline for zero parameters is 4.
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 lists procedures from a published catalog, specifying the returned fields (slug, display_name, also_known_as, specialty_slug) and the condition (every procedure with a live article). It effectively distinguishes from sibling tools like get_procedure (single procedure) and list_specialties (specialties only).
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 implies usage for retrieving all procedures that have live articles, which contrasts with get_procedure (presumably for a single procedure) and find_specialists_by_procedure (finding specialists). However, it does not explicitly state when not to use this tool or provide comparisons to siblings.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It indicates a read-only list operation and specifies the output fields. No contradictions or missing critical behaviors.
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 consists of two succinct sentences. The first sentence states the purpose and output, and the second provides usage guidance. Every word adds value, with no extraneous content.
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 parameterless tool with no output schema, the description is complete. It explains what the tool returns and when to use it, providing sufficient context for an AI agent to invoke it correctly.
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 has no parameters, so the schema coverage is 100%. Per guidelines, the baseline score is 4 since no parameters need explanation. The description does not need to add parameter semantics.
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 that the tool lists veterinary specialty slugs as a closed-set enum, and specifies the returned fields (slug, display_name, credentialing_board.sameAs). It distinguishes itself from sibling tools by advising to call it before search_clinics for specialty mapping.
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 explicitly instructs when to use the tool: 'Always call this before search_clinics if uncertain about specialty mapping.' This provides clear context, though it does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_for_caseAInspect
Composite tool. Always computes an estimate. When owner_email is also present, additionally submits a confirmation-gated lead and dispatches a confirmation email to the owner (requires X-Agent-Attribution header). When PII is absent, behaves identically to estimate_procedure_cost and returns status="estimate_only".
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ||
| case_notes | No | Optional. Free-text notes from the owner for the receiving clinic. | |
| owner_name | No | Optional. Required if owner_email is present. | |
| owner_email | No | Optional. When present, triggers the lead-capture write path and requires X-Agent-Attribution. | |
| owner_phone | No | Optional. | |
| case_factors | Yes | Same shape as estimate_procedure_cost.case_factors. | |
| procedure_slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses composite nature, conditional behavior based on owner_email, header dependency, and return status for estimate-only mode. Since no annotations are provided, the description carries the full burden and does so adequately, though it could mention error handling.
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?
Single well-structured paragraph, no wasted words. Front-loaded with core purpose, then conditional logic. Perfectly concise for the complexity.
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?
Covers both operational modes, required header, and return status. For a tool with 7 parameters, nested objects, and no output schema, this is sufficient. Lacks detail on error scenarios (e.g., missing header), but overall complete.
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?
Adds meaningful context beyond the schema: owner_email triggers lead capture and requires X-Agent-Attribution; owner_name is required when owner_email is present; case_factors references another tool's parameter. Schema coverage is 71%, and description provides necessary behavioral constraints.
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?
Clearly states it is a composite tool that always computes an estimate and conditionally submits a lead when owner_email is present. Distinguishes itself from estimate_procedure_cost by noting identical behavior when PII is absent.
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 clear guidance on when to use this tool vs. estimate_procedure_cost: when owner_email is present, it triggers lead capture; when absent, it behaves like estimate_procedure_cost. Mentions the X-Agent-Attribution header requirement. Could be more explicit about when to prefer the sibling, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug (e.g. "denver", "austin"). Validate against /api/agents/specialties or list_specialties. | |
| limit | No | ||
| state | No | Optional 2-letter state slug ("co", "tx", "ca"). Disambiguates same-name cities. | |
| specialty | Yes | Specialty slug (e.g. "orthopedic-surgery", "oncology", "emergency-critical-care", "generalist"). Closed set; use list_specialties. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are ranked, with promoted listings first, and lists output fields. This adds useful behavioral context beyond the name, though it omits side effects or error handling.
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?
Two sentences: one for purpose, one for output and ranking. No wasted words; each sentence earns its place. Front-loaded with purpose.
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?
No output schema, so description should fully explain return values. It lists fields but not their types or the 'contact action' meaning. Lacks prerequisites or limitations beyond schema hints. Adequate but not complete.
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 75% (3 of 4 params documented). The description adds no new parameter semantics beyond the schema; it only reiterates city and specialty. Baseline is 3 due to high 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 description clearly states the tool finds veterinary specialty clinics by city and specialty, and lists the returned fields (credentials, address, rating, etc.). It distinguishes from siblings like get_clinic (single clinic) and list_specialties (list of specialties).
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 implies when to use (searching clinics by city+specialty) but does not explicitly mention when not to use or compare with alternatives like find_specialists_by_procedure. Usage context is implicit but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!