Location History

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely useful operational context beyond that: a $0.10 cost and requirement of an API key. It still says nothing about result volume, pagination, or the merge/deduplication behavior implied by 'Merges'.

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 compact sentences, front-loaded with the core purpose; the cost/auth parenthetical is efficient. It is telegraphic rather than wasteful, though the fragment style ('MCP/Uber digs') is an in-joke that consumes space without adding meaning.

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?

An output schema exists, so return format need not be described, and the safety profile is covered by annotations. The remaining gap is the six entirely undocumented filter parameters, which leaves an agent guessing about how to scope a query.

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 description coverage is 0%, so six parameters (to, from, city, place, country, precision) are documented nowhere. The description only hints at the precision dimension via 'venue-level by default'; it never explains what the date, city, place, or country filters do or how they combine.

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?

States a specific verb+resource ('Normalized visit history') and adds scope detail (venue-level by default) plus the data sources it merges (GPS location_visits + place_visits), which helps separate it from get_place_visits. It does not explicitly name the sibling alternatives, so it stops short of a 5.

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?

No guidance on when to call this versus get_place_visits, get_travel_history, get_location_context, or get_cities_visited, all of which sit adjacent in the sibling list. The only usage signal is the implied default granularity (venue-level), which is not framed as a selection criterion.

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