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

Adds substantial behavior beyond the annotations: a credit/cost model ('uses one read per 20 places'), a persistent side effect ('saved in the user's Puley history'), and a hard output cap ('up to 60'). The history-saving disclosure is especially valuable because it explains why readOnlyHint is false despite this being a lookup, so the agent will not assume the call is free of side effects.

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?

Dense and front-loaded: the resource and return fields come first, then cost/limit, then scope exclusions. It is a single run-on block rather than structured lines, but no sentence is filler and each clause carries operational information.

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 three-parameter tool with no output schema, the description supplies the return shape, the cost model, the result cap, the persistence side effect, and the scope boundary. An agent has everything needed to decide whether to call it and what to expect back.

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?

With 0% schema description coverage the description has to carry the parameter burden, and it mostly does: query is illustrated with a concrete 'coffee shops' in 'Austin, TX' shape, and limit is bounded ('up to 60') against the schema's bare default of 20. The location parameter is only implied by the example format rather than described directly, leaving a small 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?

States a specific verb and resource ('List the businesses or places Google Maps shows for a search') and enumerates the returned fields (name, category, rating, review count, address, phone, website, open-now, Maps link). It also draws a hard boundary against the nearest sibling category with 'Business listings only; never people', separating it from find_leads and find_contact.

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?

Gives clear when-not guidance: 'Business listings only; never people' and 'Meant for research, not bulk marketing messages', which steers the agent away from lead-gen/outreach use. It stops short of naming a specific alternative tool to use instead for people or bulk messaging, so the routing is implied rather than explicit.

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