Veterical Vet Clinic

Book a vet appointment

book_appointment

DestructiveIdempotent

Use this when someone asks to book an animal in for a visit at their vet clinic. Returns the new appointment with its time, provider ids and procedure count; it takes the clinic's usual length and reminders, so the clinic's reminder messages go to the animal's owner. Not for vaccinations, which are booked in Veterical.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "patientId": "<patientId>",
      "startTime": "<startTime>",
      "requestId": "<requestId>"
    },
    "name": "book_appointment"
  }
}

Input Schema

Name	Required	Description
`clinicId`	No	Id of the clinic, from list_clinics. Leave it out when the user has one clinic.
`patientId`	Yes	Id of the animal, from find_patient or create_patient. It needs an owner on file.
`requestId`	Yes	A unique id you choose for this booking, such as a UUID. Calling again with the same requestId returns the first booking rather than booking twice.
`startTime`	Yes	Start as an ISO 8601 time with the clinic's UTC offset, such as 2026-11-20T10:00:00+01:00.
`providerIds`	No	Ids of the vets, nurses or assistants who take it, from list_clinic_providers. Leave it out when the clinic has one or the user takes appointments.
`procedureIds`	No	Ids of the procedures booked, from list_procedures. A vaccine is refused.
`durationMinutes`	No	Length in minutes. Leave it out for the clinic's usual appointment length.

Output Schema

Name	Required	Description	Default
`status`	Yes
`appointment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the write/idempotent/destructive profile, and the description adds real value on top: it discloses that the clinic's usual length and reminder settings are applied by default, and that reminder messages go to the animal's owner. It stops short of saying whether availability is validated or what happens when the slot is taken.

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?

It is short and front-loaded, leading with the trigger before return behavior and the vaccination exclusion. The middle clause about clinic length and reminders is slightly compressed and reads as two ideas in one sentence, but nothing is wasted.

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?

With an output schema available and a fully documented 7-parameter schema, the description only needs to supply trigger, exclusion, and side-effect context, all of which it covers. An agent has enough to call this correctly.

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 coverage is 100%, so every parameter already carries its own meaning, including requestId idempotency, timezone-bearing startTime, and the providerIds/procedureIds source tools. The description only reinforces the durationMinutes default ('takes the clinic's usual length'), so the baseline 3 applies.

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 names a specific verb and resource ('book an animal in for a visit at their vet clinic') and explicitly scopes itself apart from a sibling area by excluding vaccinations, which 'are booked in Veterical'. An agent can distinguish this from reschedule_appointment or cancel_appointment without opening the schema.

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 an explicit trigger ('when someone asks to book an animal in for a visit') and one clear exclusion ('Not for vaccinations'). What's missing is routing for adjacent intra-toolset cases, such as whether changing an existing booking should go to reschedule_appointment instead.

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

All Veterical Vet Clinic 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?