Veterical Vet Clinic

Update an animal's details

update_patient

DestructiveIdempotent

Use this when someone asks to rename an animal, correct its species or breed, or record its owner. Returns the animal's id, name, clinic and which fields changed. Not for adding a new animal.

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>",
      "expectedLastEditTime": "<expectedLastEditTime>"
    },
    "name": "update_patient"
  }
}

Input Schema

Name	Required	Description
`name`	No	New name.
`breed`	No	New breed.
`species`	No	The species: dog, cat, rodent, bird, reptile, horse, livestock or other.
`clientId`	No	Id of the animal's owner at its clinic, from find_client or create_client.
`patientId`	Yes	Id of the animal, from find_patient.
`expectedLastEditTime`	Yes	The lastEditTime from find_patient. An animal changed since then is refused.

Output Schema

Name	Required	Description	Default
`status`	Yes
`patient`	Yes
`changedFields`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=true, so the safety profile is largely pre-supplied. The description adds that the result reports 'which fields changed', which hints at partial-update semantics, but it never addresses the destructiveHint concern directly — an agent is left unsure whether fields omitted from the call are cleared or preserved, and the optimistic-concurrency refusal is only documented in the schema.

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?

Three short sentences, front-loaded with the trigger condition, then the return shape, then the exclusion — no filler or repetition. Every sentence carries decision-relevant information.

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?

The tool has six parameters, a full schema and an output schema, and the description covers the trigger, the exclusion and (redundantly) the return shape, so an agent has enough to call it. The one omission is that partial-update semantics versus a destructive overwrite is never clarified, which matters for a tool flagged destructiveHint=true.

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 100%, so every parameter including the optimistic-lock field expectedLastEditTime and the clientId source (find_client/create_client) is already documented in structured data. The description's mentions of name, species/breed and owner merely restate those fields without adding format, enum or constraint detail; 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 (updating an animal) and enumerates the concrete sub-actions: renaming, correcting species or breed, and recording the owner. It also explicitly separates itself from the closest sibling by stating 'Not for adding a new animal', so an agent can route between update_patient and create_patient without opening either schema.

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

Usage Guidelines5/5

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

It gives an explicit trigger ('Use this when someone asks to rename an animal, correct its species or breed, or record its owner') and an explicit exclusion ('Not for adding a new animal'). Both the when and the when-not are stated, which is the full bar for this dimension.

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?