Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_google_map_nearby

Search nearby stored Google Maps businesses. Searches stored Google Maps businesses near a coordinate in dataset id enum value google-map-businesses.

Instructions

Search nearby stored Google Maps businesses. Searches stored Google Maps businesses near a coordinate in dataset id enum value google-map-businesses. category is the exact Google Maps category label returned for the business locale; it can be localized, non-ASCII, or contain punctuation, so use the category facet to discover exact filter values. A rating of null means no aggregate rating is available. A review_count of null means Google did not return a count; numeric 0 means Google confirmed zero reviews. min_rating above 0 excludes unrated businesses. Billing: this endpoint costs 1 credit per record returned, with a minimum of 2 (an empty result costs 2, a full page of 100 costs 100).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude
lonYesLongitude
pageNoPage number, defaults to 1
categoryNoExact locale-specific Google Maps category label; use the category facet to discover values, max 128 characters
radius_mYesRadius in meters, max 50000
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000
min_ratingNoMinimum rating, 0 through 5. Businesses with no aggregate Google rating are returned with rating null, so any min_rating above 0 excludes them.
min_review_countNoMinimum review count

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"Exact category filter: a Google Maps type token in lower-case snake_case (e.g. dentist, bus_stop), max 128 characters"New value: +"Exact locale-specific Google Maps category label; use the category facet to discover values, max 128 characters"
  2. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / category / description
      Previous value: -"Exact category filter, max 128 characters"New value: +"Exact category filter: a Google Maps type token in lower-case snake_case (e.g. dentist, bus_stop), max 128 characters"
    • changedInput schema / properties / min_rating / description
      Previous value: -"Minimum rating, 0 through 5"New value: +"Minimum rating, 0 through 5. Businesses with no aggregate Google rating are returned with rating null, so any min_rating above 0 excludes them."
  3. Addedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses billing (1 credit per record, minimum 2, empty result costs 2, full page of 100 costs 100), distinguishes rating/review_count null from numeric 0, and explains the min_rating exclusion side effect. These are non-obvious operational traits an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and keeps each sentence purposeful (category guidance, null semantics, billing). It is dense and repeats the min_rating explanation already present in the schema, costing a little efficiency but not clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter search with no output schema, the description covers filtering semantics, null handling, and cost, which is most of what an agent needs. It stops short of describing result shape or pagination behavior beyond the schema's page/page_size notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all eight parameters, giving a baseline of 3. The description adds some interpretation (localized/punctuated category labels, null vs 0 semantics, min_rating exclusion) but largely restates what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ("Search nearby stored Google Maps businesses") and pins the dataset ("google-map-businesses"). It conveys the geo-radius scoping that separates it from datasets_google_map_search, though it never names that sibling explicitly, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real context on how to use the tool: category labels are localized/non-ASCII so the agent should consult the category facet to discover valid values, and min_rating above 0 excludes unrated businesses. It steers value discovery to another tool but does not explicitly contrast when to prefer this over datasets_google_map_search.

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

Deploy Server

Other Tools