maps_search

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

No annotations, so the description carries the full behavioral burden. It does disclose the pricing model and payment rail (0.03 USDC on Base via x402) and hints that calls are billable, which is valuable. However it says nothing about latency, rate limits, caching, or the repeat-purchase semantics beyond the parameter text.

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?

A single sentence, but it bundles three unrelated ideas (result contents, cost, payment protocol) with no front-loaded structure. It is not wasteful, yet the parenthetical pricing coda is harder to parse than a separate sentence would be.

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?

A paid, non-idempotent search tool with 5 parameters, no annotations, and no output schema. The description never explains return shape, result ordering, pagination via limit, or what happens on repeat calls, leaving major gaps for an agent deciding whether to spend money.

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 40%: keyword and confirmNewPurchase are documented, but limit, language_code, and location_code have no descriptions anywhere. The description itself adds no parameter detail, so the geographic and language defaults (de, 2276) remain opaque.

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 ('Google Maps results for a search') and enumerates the returned fields (rating, address, phone, website), which is more specific than most siblings. Sibling set is huge and contains adjacent tools like local_businesses and service_search, but the description never distinguishes itself from them, keeping it out of 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 when-to-use context, no mention of when a sibling like local_businesses would be the better choice. The only conditional guidance is buried in the schema for confirmNewPurchase, not in the description.

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