VetClinic.info — Veterinary Specialty Directory

quote_for_case

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".

Input Schema

Name	Required	Description
`zip`	No	US ZIP. Optional.
`city`	No	City slug. Optional; helps route to a practice near the owner.
`state`	No	US state code or name. Optional.
`case_notes`	No	Optional. Free-text notes from the owner for the receiving clinic.
`owner_name`	No	Optional. The email's local part is used if omitted.
`owner_email`	No	Optional. When present, submits the quote request (accepted on arrival) and requires X-Agent-Attribution.
`owner_phone`	No	Optional.
`case_factors`	No	Same shape as estimate_procedure_cost.case_factors. Optional.
`procedure_slug`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 8, 2026

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"
+]

First observedMay 22, 2026

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 and does so well: it discloses the composite dual-mode behavior, the X-Agent-Attribution auth requirement when PII is supplied, the side effects (routing to a specialist, holding for matching, receipt email), and the returned status value. It omits error/rate-limit behavior and any statement about cost or reversibility of the submitted case.

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?

Roughly four sentences, front-loaded with the always-true behavior before the conditional branch, so an agent skimming gets the core contract first. The prose is terse and jargon-heavy ('accepted on arrival', 'held while we match one'), but every clause conveys a distinct behavior.

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 9-parameter composite tool with no annotations and no output schema, the description covers the essential decision logic and the one return value that matters (status='estimate_only'). It leaves the shape of the estimate payload and failure modes unstated, which is a modest gap given the missing output schema.

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 description coverage is 89%, so the baseline is 3, but the description adds real semantic weight by framing owner_email as the switch between estimate-only and case-submission modes and by tying routing to locality fields. It also confirms case_factors mirrors the sibling tool's shape, giving the agent confidence the two are interchangeable.

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 opens with the specific nature of the tool ('Composite tool. Always computes an estimate') and then spells out the two distinct behaviors (estimate-only vs. full case submission with routing and receipt). It explicitly distinguishes itself from the sibling estimate_procedure_cost by stating the exact condition under which the two are identical.

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?

It gives a clear conditional trigger: include owner_email to accept the case on arrival and get routing/receipt behavior; omit it and the tool collapses to estimate_procedure_cost. It names the alternative and the pivot parameter, though it never says outright 'use estimate_procedure_cost when you have no PII', leaving a small inference step.

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

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

Need Help?