Extract verified business leads, addresses, ratings, and phone numbers from Google Maps by entering a search query and setting a result limit.
Extract verified business leads, addresses, ratings, and phone numbers from Google Maps. Backed by captainhandsome/google-maps-business-search.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Number of leads to retrieve (1-100) | |
| search_query | Yes | e.g. 'HVAC contractors in Phoenix, AZ' |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and it discloses almost nothing: no read-only/rate-limit note, no pagination behavior, no failure modes, and no statement that results come from an external scraper. The word 'verified' implies a data-quality claim but is never qualified. Minimal disclosure for a tool with zero annotation coverage.
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?
The purpose is front-loaded in the first sentence, which is good. The second sentence is provenance metadata of dubious value to an invoking agent, so half the description does not earn 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 tool with full schema coverage and no output schema, the description is just barely enough – it names the kind of data returned (leads, addresses, ratings, phone numbers). It omits any query-format guidance beyond the schema example and any note on result quality or limits, leaving it adequate but thin.
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 100% – search_query has a concrete example ('HVAC contractors in Phoenix, AZ') and max_results documents its 1-100 range with a default of 10. The description adds no syntax, formatting, or semantic 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?
States a specific verb ('Extract') and resource ('business leads, addresses, ratings, and phone numbers from Google Maps'), so an agent immediately knows the domain and output. Sibling tools cover entirely different domains (jobs, filings, contracts, streams, listings), so no explicit differentiation is needed. The trailing 'Backed by captainhandsome/...' clause is provenance trivia that adds no selection signal.
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 gives no guidance on when to use this tool versus alternatives, nor any trigger conditions or exclusions. Usage is only inferable from the name and the example query in the schema. Nothing tells the agent how this differs from a general web search or when it would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.