highbrow_fame data APIs (pay per call)

Business leads from a Google Maps search, with e-mails

maps_leads

Read-only

Business leads for a Google Maps search such as "dentist in Austin, TX": name, category, address, phone, website, e-mail addresses read from the business website with a deliverability grade, social links, rating, review count and a lead score. Suited to local lead generation and prospect lists. $0.007 per lead requested, 1 to 20 leads per call; a call typically takes 1 to 2 minutes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "maps_leads"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum businesses (1 to 20, default 10). A search takes about 70 seconds to start and 5 to 8 seconds per business; after about 110 seconds it returns the businesses it has (a note says so), so a large limit can return fewer rows.
`query`	No	What to look for and where, 3 to 200 characters, e.g. "dentists in Austin, TX" or "Italian restaurants in Manhattan". Specific searches work better than broad ones.
`emails`	No	true (default): read each business website for e-mail addresses and grade the best one (primaryEmail, emails, emailValidation). false: faster, the e-mail fields are left out.
`socials`	No	true (default): add the Facebook, Instagram, LinkedIn, X, YouTube and TikTok links found on the website (socialMedia). false: socialMedia is left out.
`language`	No	Language of the Google Maps listing as a 2-letter code (default en), e.g. de, fr, es.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, it discloses pricing, the 1-to-20-leads-per-call range, expected runtime of 1 to 2 minutes, and that e-mail addresses are read from the business website and graded for deliverability. This is substantial operational context for a read-only, open-world search tool.

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 definition is front-loaded with purpose, then output fields, then cost and timing constraints. Despite being dense, every clause earns its place, especially since there is no output schema.

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?

For a tool with no output schema, the description sufficiently explains what comes back, including e-mail validation, social links, ratings, review counts, and lead score. It also covers cost, runtime, and call limits, leaving no major operational gaps.

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?

The input schema has 100% description coverage and already explains each parameter, including defaults and trade-offs. The description reinforces a few meanings such as the 1-to-20 limit and website-derived e-mails, but adds little parameter syntax or behavior 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 resource and scope: business leads for a Google Maps search, including the fields returned. It clearly distinguishes this from generic search siblings by tying the output to local business lead generation and website-derived e-mail addresses.

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?

It gives a clear usage context: "Suited to local lead generation and prospect lists." It also states cost and call limits, but does not explicitly name when not to use it or compare it against sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All highbrow_fame data APIs (pay per call) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?