Manually mark a pet as inside or outside when its chip was not read, such as using a non-flap door, to correct a stale tracked location.
Manually mark a pet as inside or outside. Useful when a pet was let through a door other than the flap, so its chip was never read and the app's tracked location is stale.
| Name | Required | Description | Default |
|---|---|---|---|
| petId | Yes | Numeric pet ID (from list_pets) | |
| location | Yes | Where the pet actually is |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that this overrides a stale automatically-tracked location. However, it omits whether the manual value persists, whether it is overwritten by the next chip read, and whether it affects reports or notifications — meaningful gaps for a state-mutating tool.
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, zero waste, with the action front-loaded and the rationale following. Every sentence 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 two-parameter, enum-constrained tool with no output schema, the description covers purpose and the motivating scenario adequately. The remaining gap is behavioral persistence and side effects, which is minor at this complexity but not fully closed.
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% and the enum is documented, so the schema already defines both parameters fully (petId sourced from list_pets, location constrained to inside/outside). The description adds no syntax, format, or edge-case detail beyond that, so the baseline 3 applies.
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 names a specific verb and resource ('manually mark a pet as inside or outside') and immediately frames it as a manual override of tracked state. It does not explicitly contrast itself with siblings like get_pet_report or get_pet_details, but the action is unambiguous among the listed tools.
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?
It gives a concrete trigger: a pet was let through a door other than the flap, so the chip was never read and the tracked location is stale. That is a clear when-to-use condition. It stops short of naming an alternative (e.g. checking the report first) or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.