Skip to main content
Glama
Sign In
Local Business Lead Builder MCP Server

Local Business Lead Builder MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Build local business leads

build_local_business_leads
Read-only

Build local business lead lists from Google Maps by category and location, returning names, websites, phones, addresses, ratings, reviews, and hours with rating, review, website, and phone filters.

Instructions

Build a local business lead list from the public Google Maps search results. Give queries such as dentist in Austin, TX, or categories plus locations to search every pair. Returns one row per business: name, Google place ID and Maps link, website and domain, phone, full address, latitude and longitude, categories, star rating, review count, and weekly hours, plus one free summary row per search with its counts. Filters for minimum rating, minimum reviews, website, and phone drop businesses before they are billed; a business found by two searches is returned once. Blocked or empty searches come back free with a row_status saying so. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per business row returned.

Input Schema

NameRequiredDescriptionDefault
dedupeNoSkip a business an earlier search in the same run returned. Default true.
countryNoTwo letter country code Google uses to rank results. Default us.
queriesNoSearches the way you type them in Google Maps: a business category and a place, for example dentist in Austin, TX. Up to 100 per run.
languageNoTwo letter language code for the results. Default en.
locationsNoPlaces to search in: a city with its state or country, a ZIP code, or a neighborhood. Combined with every category.
categoriesNoBusiness categories, for example roofing contractor. Each is searched in every location.
min_ratingNoKeep only businesses rated at or above this, for example 4.0. Filtered businesses are not billed.
proxy_modeNoauto uses the Apify proxy and moves a refused request to residential addresses; residential uses residential only. A reliability choice; proxy use adds nothing to the price. Default auto.
min_reviewsNoKeep only businesses with at least this many Google reviews.
require_phoneNoSkip businesses with no phone. Default false.
max_charge_usdNoOptional. The run stops before any row that would take its charges over this amount.
require_websiteNoSkip businesses with no website. Default false.
max_places_per_queryNoPlace rows per search, 1 to 500. Each place row is billed. Default 20.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations with billing semantics (per-row charges, filters applied before billing, blocked/empty searches returned free with row_status), dedupe behavior, error-with-run-ID handling, and the APIFY_TOKEN requirement. This is exactly the cost and failure context an agent needs before committing to a paid run.

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?

One dense paragraph, but front-loaded with purpose, then return shape, then cost/failure behavior — the order an agent needs. A few clauses (weekly hours enumeration, domain vs website) could be trimmed, keeping it short of a 5.

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

Completeness5/5

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

With 13 optional parameters and no output schema, the description carries the return-shape burden itself by enumerating the per-business fields and the free summary row. Cost model, auth requirement, and failure mode are all covered, so nothing critical is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description adds cross-parameter meaning the schema states only piecemeal: filters drop businesses before billing, and a business found by two searches is returned once. It also contrasts the query and categories/locations modes, though individual defaults like max_places_per_query and country are left to the schema.

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

Purpose5/5

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

States a specific verb and resource — 'Build a local business lead list from the public Google Maps search results' — and immediately names the two input modes (free-form queries vs. categories plus locations). No sibling tools exist to differentiate from, so the identification burden is fully met.

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 concrete invocation guidance ('Give queries such as dentist in Austin, TX, or categories plus locations to search every pair'), which tells the agent how the two search modes behave. It does not state exclusions or when-not-to-use, but there are no alternatives to route against, so the gap is minor.

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