Skip to main content
Glama
hubertino-app

Hubertino MCP Server

Official
by hubertino-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get scrape results (lead rows)

get_results
Read-only

Retrieve scraped Google Maps business leads as paginated JSON pages. Filter by fields or email-only, and page with offset until all rows are read.

Instructions

Read a scrape's rows as compact JSON, one page at a time. Works while the scrape is running (partial rows) and after it is done. Long pages are cut short to fit one tool response (trimmed: true); keep paging from nextOffset. Each row is one business with only its populated fields, e.g. name, category, phone, email, website, address, city, state, postal_code, country_code, rating, reviews, business_status, company_facebook/instagram/linkedin/x/youtube, location_link, place_id and _status (found -> extracted -> enriched). Page with offset/nextOffset until hasMore is false. For a spreadsheet of every row use download_export instead of paging through thousands of rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRows per page (1-1000, default 50).
detailNocompact (default) drops long or duplicate columns (coordinates, opening hours, internal ids, links to order/reserve) and shortens very long text; full returns every populated column.compact
fieldsNoOnly return these columns, e.g. ["name","email","phone","website"]. Overrides detail. Available columns include query, name, category, phone, email, website, domain, company_facebook, company_instagram, company_x, company_youtube, company_linkedin, address, street, city, state, state_code, postal_code, country, country_code, latitude, longitude, plus_code, rating, reviews, business_status, price_range, service_options, working_hours, order_links, reservation_links, menu_link, location_link, place_id, google_id, cid, kgmid, _status.
offsetNoRows to skip (default 0). Use nextOffset from the previous page.
scrapeIdYesThe scrape id returned by start_scrape or list_scrapes (a UUID).
withEmailOnlyNoOnly return rows that have an email address. Filters within the requested page.

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 the annotations (readOnlyHint, openWorldHint), the description reveals significant behavior: partial rows are visible while the scrape runs, long pages are trimmed with trimmed: true, rows include only populated fields, and _status transitions found -> extracted -> enriched. No contradiction with annotations.

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 key purpose is front-loaded in the first sentence, and each following sentence adds needed operational detail: when it works, trimming/paging, row shape, status progression, and the download_export alternative. There is no filler.

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?

Despite having no output schema, the description compensates by defining the row format (one business per row, populated fields only), the field vocabulary, the _status lifecycle, and pagination mechanics (nextOffset, hasMore, trimmed). This gives an agent enough to call and interpret results.

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 description coverage is 100%, and each parameter already has a clear description for limit, detail, fields, offset, scrapeId, and withEmailOnly. The description reinforces paging with nextOffset and mentions compact JSON, but it adds no parameter-level meaning beyond what the schema already provides, so baseline 3 applies.

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 opens with a specific verb and resource: 'Read a scrape's rows as compact JSON, one page at a time,' which clearly distinguishes this from siblings like start_scrape and wait_for_scrape. It also explicitly contrasts itself with download_export for spreadsheet-download use cases, so the tool's role is unmistakable.

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 says exactly when to use this tool — to page through scrape rows, both while running and after completion — and when not to: 'For a spreadsheet of every row use download_export instead of paging through thousands of rows.' It also gives the paging pattern (offset/nextOffset until hasMore is false).

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