Google Maps Places API Alternative: Businesses, Ratings and Contacts via API and MCP

A Google Maps Places API alternative is a way to get local business data (names, addresses, phone numbers, websites, ratings, review counts and opening hours) without building on Google's own developer platform. NeuralVerge's Google Maps search source takes search terms and an area and returns matching places as JSON, billed per place returned. Reach it by API or MCP; the source page is the reference for exact fields and prices.

The short version

• —The answer. For place lists (every dentist in a postal code, every roaster in a city), a source that takes a search and returns flat JSON saves the pagination, area tiling and address parsing a direct integration needs. For place data shown to end users inside your app, build on the platform made for that.
• —Who it is for. Sales and agency teams building call lists, field teams planning territories, analysts sizing a market, and agents that need to answer "who is near here" as a tool call.
• —What it costs. 5 points per returned place, which the source page states as $5 per 1,000 places, plus 2 points per place for each active filter. A search that finds nothing costs nothing. Points come from a monthly plan on the pricing page.
• —What you give up. No review text, and phone, website and hours are owner-maintained, so they can be missing or out of date.

What places data means

Three different jobs get called "Google Maps data". Separating them makes the rest of this post easier to follow.

Maps and routing

Rendering a map in an app, drawing routes, geocoding an address, showing a pin on a store locator. This is a mapping job. It needs map tiles, a client library and an embedded experience. A data source that returns JSON does not replace it, and this post is not about it.

A lookup inside your own product

An address autocomplete box, a "pick the nearest branch" widget, a place detail card shown to end users. Here the places platform is part of your product's interface. It is built for that, with client libraries and session handling designed around a person typing into a form.

Places as a dataset

Pulling every dentist in a postal code, every coffee roaster in a city, or every contractor in a state, then working with the list: filtering it, scoring it, loading it into a CRM, counting it, or handing it to an agent. Nobody is typing into a box. The job is list-shaped, and the unit of work is "all places matching this search", not "one place the user just tapped".

The third job is what this post is about. It is also the job where building directly on a platform API takes the most plumbing, because you are the one who has to turn a search into a complete, deduplicated list.

When a Google Maps Places API alternative makes sense

What list-shaped work on a places API involves

We have not tested Google's API for this post, so treat the following as the general shape of the work, to be checked against Google's documentation. A direct integration usually means you own these pieces:

1. —An account and credentials. A cloud project, a billing account, an API key with sensible restrictions, and a way to rotate it.
2. —Field selection. Platform APIs commonly let you choose which fields to request and price by the group of fields you ask for. That is flexible, and it also means cost depends on a field list you have to get right.
3. —Pagination. One search returns a bounded number of results. A full list means following continuation tokens until they run out.
4. —Area tiling. If a single search caps the number of results it gives for an area, covering a large city means splitting it into smaller cells, searching each, and deduplicating places that appear in more than one.
5. —Normalisation. Turning address components into the street, city, state and postal-code fields your CRM expects.
6. —Terms of use. What you may store, for how long, and how you may display it. These rules are specific and change, which is why they belong on your checklist rather than in a blog post.

None of this is hard, and plenty of teams do it well. It is still a real amount of code for a team whose goal is a call list.

Three ways to get the list

The table is qualitative on purpose: how a platform API prices a full list depends on your fields and request count, and we do not quote Google's prices.

When to build on the platform instead

A fair comparison includes the cases where we are not the right answer. Choose a direct places platform integration if:

• —You need place data inside an end-user interface, such as autocomplete or a place card, where client libraries and session handling are designed around that.
• —You need fields this source does not return, such as review text.
• —Your use case depends on a licence or term that only a direct agreement gives you. Check the provider's current terms for what is permitted.

Choose the NeuralVerge source if you want places as a list, a per-place price you can calculate in advance, a response with address components already split out, and the same account that also runs research, extraction and enrichment.

How the source works

The Google Maps search source is one of the data sources in the NeuralVerge platform. The mechanism is short.

1. You describe the search

Send one or more search terms (up to five, comma-separated) and an area. The area can be free text such as "Austin, USA", or structured: country, state, county, city or postal code. For a radius around a point, pass a custom GeoJSON shape with a radius in kilometres.

2. You choose how many places and which filters

max_items sets how many places to return per search term, from 1 to 1,000, with a default of 20. Optional filters narrow the results before you pay for them: categories, exact or partial name matching, a minimum rating, with or without a website, and skipping closed places. Each active filter adds to the price per place, covered in the cost section.

3. The search runs inside the request

The call is synchronous. It blocks until the search completes and returns the places directly, with no job id to poll. If the search reaches its time budget first, the response comes back with partial: true and the places collected so far, and you can re-run with a smaller max_items.

4. You get flat, typed JSON

Each place carries the groups of fields below. The response also carries the session_id, the search terms, the location and what the search cost, so every result can be traced to the request that produced it. The table is from the source page, at the time of writing.

5. You hand the list to the next step

The output is a list of plain objects. Load it into a table, export it from the app, filter it in code, or let an agent reason over it. If you then need an email for a business, the Facebook page contacts source reads contact details from a business's page, and an email finder covers the person-level case. Both are priced separately.

A worked example

Suppose Acme Oy (a made-up Finnish company, used as an example only) sells scheduling software to dental clinics and wants a first call list for one city.

1. —Acme Oy sends a search for "dental clinic" in a named city, with max_items at 100 to start, and reads the first response to check the fields it needs are populated.
2. —It turns on the minimum-rating filter and the website filter, because the sales team only wants clinics with a site to inspect. Each place now costs 9 points, and the response shows active_filters so the charge is visible.
3. —It reads phone and website for each place. Where the phone is null, it follows up another way, for example with the Facebook page contacts source or an email finder, each priced on its own.
4. —It uses latitude and longitude to group clinics into walking and driving routes, and rank only as a hint about prominence on the map.
5. —It re-runs the search later as a fresh request. Each run reads the data at request time, so a clinic that has since closed shows up as closed instead of lingering in a stale export.

REST and MCP

The same source is reachable both ways: a REST call, or the run_google_maps_search tool on the hosted MCP server. Only the transport differs; the search, the filters, the price and the response are the same. The request below is the REST example from the source page: two search terms, 100 places each at most, closed places skipped.

curl -X POST https://api.neuralverge.ai/functions/v1/run-google-maps-search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "search_terms": "coffee shop, roastery", "location": "Austin, USA", "max_items": 100, "skip_closed": true }'

The response below is a captured one from the same endpoint, for the single term "coffee shop" in "Austin, USA" with max_items set to 1 and no filters. It is shown unchanged.

{
  "session_id": "1aa2f23b-b749-4f3f-89b7-f6ea59ac24b1",
  "kind": "google_maps_search",
  "search_terms": ["coffee shop"],
  "location": "Austin, USA",
  "max_items": 1,
  "language": "en",
  "active_filters": [],
  "points_per_place": 5,
  "machine": {
    "total_items": 1,
    "partial": false,
    "items": [
      {
        "place_id": "ChIJq7RZDGczW4YRyCS5Z0KiiDE",
        "name": "Godsent Coffee",
        "category": "Coffee shop",
        "categories": ["Coffee shop"],
        "address": "9817 Anderson Mill Rd, Austin, TX 78750",
        "street": "9817 Anderson Mill Rd",
        "neighborhood": "Anderson Mill",
        "city": "Austin",
        "state": "Texas",
        "postal_code": "78750",
        "country_code": "US",
        "phone": null,
        "website": "https://www.godsentcoffee.com/",
        "rating": 5,
        "review_count": 244,
        "price": null,
        "latitude": 30.4464508,
        "longitude": -97.7971457,
        "permanently_closed": false,
        "temporarily_closed": false,
        "opening_hours": [
          { "day": "Monday", "hours": "7 AM to 3 PM" },
          { "day": "Tuesday", "hours": "7 AM to 3 PM" },
          { "day": "Wednesday", "hours": "7 AM to 3 PM" },
          { "day": "Thursday", "hours": "7 AM to 3 PM" },
          { "day": "Friday", "hours": "7 AM to 3 PM" },
          { "day": "Saturday", "hours": "8 AM to 3 PM" },
          { "day": "Sunday", "hours": "Closed" }
        ],
        "url": "https://www.google.com/maps/search/?api=1&query=Godsent%20Coffee&query_place_id=ChIJq7RZDGczW4YRyCS5Z0KiiDE",
        "search_term": "coffee shop",
        "rank": 11
      }
    ]
  },
  "total_points": 5
}

A few things worth reading off it:

• —Cost is in the response. points_per_place is 5 and total_points is 5 for one place with no filters.
• —The address is already split. Street, city, state, postal code and country code are separate fields, so there is no parsing step before the CRM.
• —Missing data is explicit. The phone is null. That is honest: the listing did not show one, and the field says so instead of guessing.
• —Rank is the map's. rank is where the place sat in the map's results for the term. It is not a distance and not a quality score.
• —Coordinates and hours are there. Latitude, longitude and day-by-day hours are enough for routing, territory splits and "open on Sunday" filters.

The same search over MCP

Through MCP, the arguments are the same ones the REST body takes:

{ "tool": "run_google_maps_search", "arguments": { "search_terms": "coffee shop", "location": "Austin, USA", "max_items": 100 } }

Tool names use underscores where REST paths use hyphens. This is the form that suits an agent: it can call the tool to answer "who are the HVAC contractors in this postal code", read structured results instead of browsing, and chain a follow-up tool for contacts. For connecting the MCP server to Claude or another client, see the MCP server guide. For parameters, limits and error handling, use the reference at https://docs.neuralverge.ai, not this post.

Cost and limits

Cost in points

The source charges 5 points per returned place. Each active filter adds 2 points per place, so a search with a minimum rating and "skip closed" costs 9 points per place. You are billed for places actually returned, capped by max_items, and a search that finds nothing costs nothing. The figures below are from the source page, at the time of writing.

Points come from a monthly plan; the pricing page lists the plans and what a point costs on each. Worked through for Acme Oy: a list of 400 clinics with a website and a rating of at least four costs 5 + 2 + 2 = 9 points per place, so 3,600 points at most. Run the same search with max_items at 100 first to see the response shape and cost before you scale it.

What you give up

• —It is a search source, not a place-detail service for end users. If your product shows a place card to a visitor inside an app, you want the platform built for that.
• —No review text. You get the rating and the review count, not individual reviews. The source page says so plainly.
• —Owner-maintained fields drift. Phone, website and hours are maintained by the business owner. They can be missing, as in the sample above, or out of date.
• —Ranking is the map's. Results are not sorted by distance. If you need "nearest first", sort on the coordinates yourself.
• —Time budget. A very large search can come back partial. Split big areas or lower max_items.
• —Read at request time. Closures and changed hours show up, and two runs of the same search can differ.
• —Terms of use sit with you. What you do with the data (store it, combine it, contact the businesses) is governed by the rules that apply to you, including local rules on outreach. Read them before you build a workflow on top.

How to decide

Run this checklist against any places data source, including ours:

1. —Does it return the fields you need? Write down your field list and test it on a real search. Do you need phone, website, hours, coordinates, category, or review text?
2. —How is it priced? Per request, per field group, per place, or a monthly fee? Work out the cost of your largest realistic list, not your smallest test.
3. —How does it handle large areas? Ask whether you have to tile an area and deduplicate places yourself.
4. —What happens on a miss? Check whether a search with no results is billed.
5. —How do you see the cost? Can you read the charge in the response, or only on an invoice?
6. —What does a partial result look like? If a search hits a limit, does the response say so?
7. —What are the terms? What may you store, for how long, and how may you use the data? Read the provider's current terms, not a summary.
8. —How do you reach it? REST, MCP, or both, and will an agent be calling it?
9. —Which use case is it? Local lead lists, websiteless prospecting (the website filter can return businesses without a site, a ready list for web agencies), territory planning from coordinates, or market sizing by category and rating all fit a list source. A place card inside your app does not.
10. —Run a real sample. Take 50 places you know in your own market and compare what each source returns against what you know to be true.

Frequently asked questions

Does this return immediately?

Yes. The search runs inside the request and the places come back in the same response, with no polling. If it reaches its time budget first, the response is marked partial: true and contains the places collected so far, so a smaller max_items gives a complete result.

How do the filter charges work?

The base price is 5 points per returned place. Each active filter (categories, name matching, minimum rating, website, skip closed) adds 2 points per place, so two filters mean 9 points per place. The response lists active_filters and points_per_place so you can check what you were charged.

Can I search several terms or a radius around a point?

Yes to both. search_terms takes up to 5 comma-separated terms, and max_items applies per term. For a radius, pass custom_geolocation as GeoJSON, such as a Point with a longitude and latitude and a radiusKm.

Does it include review text, photos or live popularity data?

No. The source returns the rating and the review count, not the text of individual reviews. Phone, website and opening hours come from what the listing shows, and owners maintain those fields, so they can be missing or out of date.

Can I use the Google Places API and NeuralVerge together?

Yes. They are not mutually exclusive. If you build a map product on Google's own platform, its API is the natural fit for that. A list-building or market-sizing job that wants places as flat JSON, paid per place returned, is where this source fits. Check Google's current terms before you decide how to combine them.

Can I use it over MCP from an agent?

Yes. The same search is available as the run_google_maps_search tool on the hosted MCP server, with the same arguments, filters and prices as the REST call. An agent can call it to get places as structured results and then call another tool for contacts.

What does a search cost?

5 points per returned place, which is $5 per 1,000 places, plus 2 points per place for each active filter. A search that finds nothing costs nothing. Points come from your monthly plan, and the pricing page lists the plans.