Skip to main content
Glama
mambalabsdev

Local Business Lead Builder MCP Server

Local Business Lead Builder MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs Local Business Lead Builder actor on Apify. Give it a business category and a place, or a search such as dentist in Austin, TX. Each run reads the public Google Maps search results and returns one row per business with website, phone, address, rating, and review count.

What's Inside

Related MCP server: maps-scrapper

What it does

Give queries (for example plumber in Austin, TX), or categories plus locations to search every pair. You get one row per business: name, Google place ID and Maps link, website and domain, phone in local and international format, full address with city, postal code, state, and country, latitude and longitude, categories, star rating, review count, and weekly hours. Each search ends with one free summary row with its counts. Filters for rating, reviews, website, and phone drop businesses before they are billed, and a business found by two searches is returned once. All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-local-business-lead-builder": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-local-business-lead-builder"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The build_local_business_leads tool appears.

Prerequisites

Example prompts

  • "Find 50 roofing contractors in Denver, CO with a website and at least 4 stars."

  • "List dentists in Manchester, UK with their phone numbers and review counts."

  • "Build a lead list of HVAC contractors in Austin, Dallas, and Houston, Texas."

Tool

build_local_business_leads. One tool. Example arguments:

{
  "categories": ["roofing contractor"],
  "locations": ["Denver, CO"],
  "max_places_per_query": "50",
  "require_website": "true",
  "min_rating": "4.0"
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.

Input

Type

Description

queries

array

Searches, for example dentist in Austin, TX. Up to 100

categories

array

Business categories, searched in every location

locations

array

Places: a city with its state or country, a ZIP code, or a neighborhood

max_places_per_query

string

Place rows per search, 1 to 500. Default 20

min_rating

string

Keep businesses rated at or above this

min_reviews

string

Keep businesses with at least this many reviews

require_website

string

true or false. Default false

require_phone

string

true or false. Default false

dedupe

string

Skip repeats across searches. Default true

language

string

Two letter language code. Default en

country

string

Two letter country code for ranking. Default us

max_charge_usd

string

Optional cost cap for the run

proxy_mode

string

auto or residential. Default auto

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

place-row, per business returned

$0.003

$0.00285

$0.0027

$0.00255

apify-actor-start, per run start

$0.0005

$0.0005

$0.0005

$0.0005

Search summary rows, blocked and error rows, filtered businesses, and skipped repeats are free.

Your keys

The actor needs no key. It reads the public Google Maps search results and holds no Google key or any other key. Proxy traffic adds nothing to your price: Mamba Labs pays the platform costs of the run. proxy_mode is a reliability setting.

Full actor documentation

apify.com/mambalabs/local-business-lead-builder

License

MIT. See LICENSE.

Available Tools

1 tool
build_local_business_leadsBuild local business leadsA
Read-only

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.

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.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedbuild_local_business_leads

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection between competing tools. Its purpose (building a local business lead list from Google Maps queries) is unmistakable from the name and description.

Naming Consistency5/5

A single snake_case verb_noun-style name (build_local_business_leads) that clearly states the action and the resource. With one tool there is no convention mixing, and the name is descriptive rather than vague.

Tool Count3/5

One tool is defensible because it wraps a single batch workflow (search, filter, and bill in one call), but it is still thin for the domain. There is no separation between starting a run, checking run status, and retrieving results, which forces everything through one opaque operation.

Completeness3/5

The core operation is richly specified, covering queries, filters, deduplication, output fields, and pricing. However, the description mentions failed runs returned with a run ID yet provides no tool to fetch or retry that run, and there is no way to list prior results or datasets, leaving dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers