Skip to main content
Glama
Sign In
Ranch.Bot MCP Server

Ranch.Bot MCP Server

Official
by RanchBot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update animal

update_animal

Update an existing animal's profile by changing only specified fields; named details merge into existing metadata so unchanged information remains intact.

Instructions

Update an existing animal's details. Pass the fields to change as the named profile fields (name, kind, sex, breed, color, birth_date, notes); they merge into the existing metadata rather than replacing it, so changing one field keeps the rest.

Input Schema

NameRequiredDescriptionDefault
sexNoSex/gender, e.g. female, male, castrated male (steer/wether).
kindNoClassification word: cow, heifer, bull, steer, ram, ewe, ewe lamb, lamb, kid, etc.
nameNoThe animal's name or call name.
breedNoBreed or cross, e.g. "Suffolk X", "Angus".
colorNoColor or markings, e.g. "white", "black white-face".
notesNoAny other standing detail (e.g. "bottle-fed", "polled"). Goes into metadata.notes.
farm_idNoThe ID of the farm (optional if a default is set).
metadataNoOptional raw metadata keys to set; merges into the existing metadata over the named fields.
animal_idYesThe UUID of the animal to update.
birth_dateNoExact date of birth as an ISO date (YYYY-MM-DD). Supply it only when the user states the date itself. If the user gives an approximate age instead, omit this field and keep that age wording in notes; never calculate or estimate a birthday from an age. On update, leave an existing birth_date and unrelated notes unchanged.
inventory_statusNoInventory status: CURRENT (default on create), UNKNOWN when current presence is unconfirmed, SOLD, DECEASED, or NOT_MANAGED when care ended without sale or death. Historical profiles remain readable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.0
    • changedInput schema / properties / birth_date / description
      Previous value: -"Date of birth as an ISO date (YYYY-MM-DD). Derive it from an age if the user gives one."New value: +"Exact date of birth as an ISO date (YYYY-MM-DD). Supply it only when the user states the date itself. If the user gives an approximate age instead, omit this field and keep that age wording in notes; never calculate or estimate a birthday from an age. On update, leave an existing birth_date and unrelated notes unchanged."
    • changedInput schema / properties / inventory_status / description
      Previous value: -"Inventory status: CURRENT (default on create), UNKNOWN when current presence is unconfirmed, SOLD, or DECEASED. Historical profiles remain readable."New value: +"Inventory status: CURRENT (default on create), UNKNOWN when current presence is unconfirmed, SOLD, DECEASED, or NOT_MANAGED when care ended without sale or death. Historical profiles remain readable."
    • changedInput schema / properties / inventory_status / enum
      Previous value: -[
-  "CURRENT",
-  "UNKNOWN",
-  "SOLD",
-  "DECEASED"
-]New value: +[
+  "CURRENT",
+  "UNKNOWN",
+  "SOLD",
+  "DECEASED",
+  "NOT_MANAGED"
+]
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is covered. The description adds a genuinely useful trait beyond that: named fields merge into existing metadata instead of replacing it. It doesn't address auth or return behavior, but the merge semantics is the key non-obvious behavior an agent needs.

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?

Two tight sentences with no filler, and the purpose is front-loaded before the merge caveat. It could carry slightly more of the parameter-handling nuance (e.g. inventory_status) without growing much, but nothing is wasted.

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 an 11-parameter mutation tool with full schema coverage, annotations covering safety, and no output schema, the description plus schema is largely sufficient. The main gap is silence on inventory_status semantics and non-replacement of existing values beyond the merge note, which the schema already handles.

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 the schema already documents every parameter, including the birth_date approximation rule and metadata merge precedence. The description's field list largely restates what is already there, 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 gives a specific verb and resource ("Update an existing animal's details") and the word "existing" cleanly separates it from create_animal/delete_animal in the sibling set. An agent can tell what it does 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 Guidelines3/5

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

It says how to invoke the tool (pass only the fields to change) but never states when to prefer it over siblings like create_animal or when writing to metadata vs named fields is appropriate. Usage is implied rather than spelled out, with no exclusions or alternatives named.

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

Deploy Server

Other Tools