Skip to main content
Glama
hubertino-app

Hubertino MCP Server

Official
by hubertino-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Start a Google Maps lead scrape

start_scrape

Start a Google Maps lead scrape by categories and locations, returning businesses with contact details, emails, websites, and social profiles for building targeted lists.

Instructions

Start a Hubertino scrape that searches Google Maps for businesses and returns them as lead rows (name, category, phone, website, email, address, rating, reviews, social profiles). Use it for requests like "find dentists in Austin with emails" or "build a list of plumbers in Leeds". Every category is searched in every location: categories x locations searches, max 2000 per scrape. COSTS CREDITS: it reserves categories x locations x maxResults credits up front (capped at the balance), charges 1 credit per business actually delivered and refunds the rest. Confirm with the user before large scrapes. Returns the scrape id immediately (status queued); then call wait_for_scrape, then get_results or download_export. Limited to 12 new scrapes per 5 minutes per account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoOptional Google edition (lower-case country code) used for the search: us, gb, ca, au, ie, de, fr, es, it, pt, nl, be, at, ch, se, no, dk, fi, pl, cz, lt, lv, ee, ro, hu, gr, br, mx, jp, in, nz, za. When omitted, Hubertino infers it from a country named in the locations and falls back to "us".
locationsYesWhere to search, one place per item: a city, region, neighbourhood or zip/postal code, e.g. ["Austin, TX, United States"], ["Vilnius, Lithuania"], ["90210, CA, USA"]. Include the country for the best match. Each category is searched separately in each location, so several smaller areas (neighbourhoods, zip codes) find more businesses than one big area. 1-10000 items, each 1-120 characters. categories.length x locations.length must be <= 2000.
categoriesYesWhat to search Google Maps for, one business type per item, e.g. ["dentist"], ["plumber", "HVAC contractor"]. Use the words a customer would type into Google Maps. 1-1000 items, each 1-120 characters.
maxResultsYesMaximum places to collect PER SEARCH (per category x location pair), 1-500. Google Maps typically returns around 100 places per search; use 500 for "everything". This also sets the worst-case credit reservation: categories x locations x maxResults (1 credit = 1 place delivered).
enrichLinksNoCollect social profiles and ordering/reservation links for each place. Default true, no extra credits.
enrichWebsiteNoVisit each business's own website to find a contact email (and social profiles). Default true, no extra credits. Keep it on whenever the user wants emails.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnly=false, non-idempotent), the description discloses substantial behavioral details: credit reservation and refund mechanics, charges per delivered business, the categories x locations cross-product limit, the 12-scrapes-per-5-minutes rate limit, and the requirement to confirm large scrapes with the user. This is exactly the kind of side-effect and cost context the annotations do not provide.

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

Conciseness5/5

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

The description is long but densely informative and front-loaded with the core purpose and examples. Cost behavior, rate limits, and next-step workflow are all essential for safely invoking this expensive operation, and no sentence is wasted.

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?

Given the tool's complexity, credit costs, and absence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers what it returns (scrape id, status queued), what will happen later (results/download), rate limits, credit accounting, and confirmation requirements.

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%, and each parameter already has a detailed description explaining meaning, constraints, and cross-field relationships. The description text reinforces the cross-product and credit behavior, but does not add significant new parameter semantics beyond 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?

The description names a specific action (start a Hubertino scrape), the resource (Google Maps businesses), and the output (lead rows with name, category, phone, website, email, and more). It clearly distinguishes itself from sibling tools like wait_for_scrape, get_results, and download_export by stating that this tool begins the scrape and returns an id.

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

Usage Guidelines5/5

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

It gives concrete use-case examples like "find dentists in Austin with emails" and "build a list of plumbers in Leeds". It also explains the follow-up sequence: returns scrape id immediately, then call wait_for_scrape, then get_results or download_export, which tells the agent exactly when and how to use this tool relative to its siblings.

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