Set or clear a mock location

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

Rich behavioral disclosure beyond the annotations: emulator path uses 'adb emu geo fix' with a specific argument order, clear on emulator is unsupported, device path requires Android 12/API 31 and injects a GPS test provider, and fused clients may ignore that provider. This is exactly the kind of platform-specific caveat an agent cannot infer from readOnlyHint/destructiveHint.

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?

Four tight sentences, each carrying a distinct platform fact, with no filler or repetition. It reads as dense reference prose rather than a front-loaded summary, but nothing is wasted.

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 platform-divergent mutation tool, the description covers the critical failure modes and prerequisites, and an output schema exists so return values need no explanation. It stops short of clarifying accuracy and validation rules for coordinates, which is the main remaining gap.

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 only 20%, so the description must compensate, and it partially does by documenting the longitude-then-latitude ordering for the emulator path. It says nothing about accuracyMeters semantics/default behavior, the action enum default, or lat/long validity constraints, leaving a real gap.

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 title and opening establish a specific verb+resource ('Set or clear a mock location'), and the body clarifies the two supported actions with real mechanism detail. It does not explicitly contrast with a sibling tool, but the sibling list contains no overlapping location tool, so ambiguity is low.

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?

The description implies usage contexts by splitting emulator vs device behavior and warns that clearing an emulator fix fails ('the console has no clear'), which is a genuine when-not-to-use signal. It never states when to reach for this tool vs any alternative, so guidance is mostly implicit.

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