Allows extraction of business leads from Google Maps, returning structured records such as business name, address, phone, website, rating, and email where published. Jobs run asynchronously and results can be downloaded after completion.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Evascrape MCP server find 200 dentists in Austin with their email addresses"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Find business leads with email addresses from inside Claude, Cursor or any other MCP client.
Ask your assistant things like:
"Find 200 dentists in Austin with their email addresses."
"Get me every plumber in Manchester with a phone number and website."
"Export this Apollo search and give me the emails."
"Build a list of CMOs at SaaS companies in California."
Evascrape runs the extraction on its own servers and returns structured records. Nothing runs in your browser and no source-platform login is used.
Create an account at app.evascrape.com.
Top up prepaid credit in the app. Top-ups start from $10. There is no free credit and no subscription.
Create a key at app.evascrape.com/account/api-keys.
Keys start with evs_live_.
Keep the key in your MCP client's config or secret store. Do not commit it to a repository.
Related MCP server: leads-mcp
Requires Node.js 18 or newer.
claude mcp add evascrape --env EVASCRAPE_API_KEY=evs_live_xxx -- npx -y @evascrape/mcpAdd this to the client's MCP config file (claude_desktop_config.json, ~/.cursor/mcp.json, ...):
{
"mcpServers": {
"evascrape": {
"command": "npx",
"args": ["-y", "@evascrape/mcp"],
"env": { "EVASCRAPE_API_KEY": "evs_live_xxx" }
}
}
}Claude Desktop users can also install the evascrape.mcpb file from the
latest GitHub release: open it with Claude Desktop
and paste the key when asked. The key is stored as a secret field.
Tool | What it does | Spends credit |
| Businesses from Google Maps: name, address, phone, website, rating, email where published | yes |
| Export a people search you already built on Apollo.io | yes |
| People from LinkedIn audiences by job title, location, company, revenue | yes |
| Check whether an extraction has finished | no |
| Read the finished records as structured data | no |
| Remaining prepaid credit | no |
| Price a job before starting it | no |
Extractions are asynchronous: a tool call starts the job and returns an id, job_status reports
progress, and download returns the records once the job has succeeded.
The three tools that start a job spend prepaid credit. Most MCP clients ask you to approve each tool
call; ask the assistant to run estimate_cost first if you want to see the price before a job starts.
Prepaid USD balance. Top-ups start from $10. No subscription, and credit does not expire.
Source | Per 1,000 records |
Google Maps | $12 |
Apollo.io | $9 |
LinkedIn / Sales Navigator | $9 |
Real-time email verification (optional) | +$5 |
You pay for delivered records: the job reserves the amount when it starts and anything that could not be delivered is refunded automatically. Verification is charged only for delivered records that have an email address. Current prices: evascrape.com/pricing.
Variable | Required | Meaning |
| yes | Key from your Evascrape account |
| no | Override the API host, for testing. Must be |
The key is sent only to https://app.evascrape.com (or the https host you set), as a Bearer header.
It is never written to stdout, logs or error messages.
Tool inputs are validated before any request is made.
Requests identify themselves with the evascrape-mcp/<version> user agent.
Only publicly available business data is collected; never private messages or login-protected content. See data sources and removal requests.
This server runs on your machine and sends your tool inputs (search terms, locations, filters, Apollo
URLs, job ids) and your API key to the Evascrape API at app.evascrape.com to run and read jobs. It
does not collect anything else and keeps no local files, logs or telemetry. Evascrape stores the jobs
and their results in your account. How Evascrape collects, uses, shares and retains data, and how to
contact us, is described in the Evascrape Privacy Policy.
Questions: info@evascrape.com.
LinkedIn jobs take filters, not a search URL. If a list comes back short, set include_unverified to true.
The same API is available directly over HTTP: evascrape.com/docs, OpenAPI at evascrape.com/docs/openapi.json.
npm install
npm testTests run the real MCP stdio protocol against a local mock API; they never call Evascrape.
MIT licensed.
Export the results of a people search you already built on Apollo.io, past Apollo's own export cap and without consuming Apollo export credits. You must supply the Apollo search URL. Only leads that have a verified email address are delivered, so the count can be lower than the number Apollo displays. Costs $9 per 1,000. Returns a job id: poll job_status, then download.
| Name | Required | Description | Default |
|---|---|---|---|
| list_name | No | Name for the export file. | |
| apollo_url | Yes | A people search URL copied from Apollo.io, e.g. https://app.apollo.io/#/people?personTitles[]=cto. The URL must carry at least one filter (job title, location, company keywords or employee size); a bare URL is rejected because it would return everything. Filters Evascrape cannot read, such as a saved Apollo persona, are ignored, so the list can come back broader than the Apollo screen showed. | |
| total_records | Yes | Maximum leads to export. Multiple of 100, minimum 100, maximum 50000. | |
| email_verification | No | Extra real-time verification for $5 per 1,000. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing cost ($9 per 1,000), the verified-email-only delivery rule and why counts differ from Apollo's display, and the asynchronous job-id-then-poll pattern. The non-idempotent, write-like nature implied by the annotations is confirmed by returning a job id rather than data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each carrying distinct load: prerequisites, edge-case behavior, cost, and the return/next-step flow. Front-loaded with purpose and constraint before the mechanics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by explaining the job-id result and how to retrieve output. Cost, prerequisites, and count caveats are all covered, leaving no gap an agent needs to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the field descriptions are already very detailed (including the filter-readability caveat), so the baseline is 3. The prose reiterates that the URL is mandatory but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Export the results of a people search') scoped to Apollo.io, which cleanly separates it from the google_maps_leads and linkedin_leads siblings. The added constraints (past the export cap, no Apollo export credits) sharpen what this tool specifically does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the precondition explicitly ('You must supply the Apollo search URL') and describes the downstream workflow by naming the sibling tools to use next: 'poll job_status, then download'. Pricing context tells the agent when this is worth invoking versus cheaper alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how much prepaid credit is left on the Evascrape account, in USD. Check this before starting a large job.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description only needs to add context beyond that. It adds the currency unit and the pre-job timing, but says nothing about return shape, staleness, or whether the balance reflects in-flight jobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the concrete fact (USD prepaid balance) front-loaded before the usage tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-argument read with rich annotations and no output schema, the description supplies enough to call it correctly and to know what the result means (USD credit). Only minor gaps remain regarding result format or freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The description correctly implies a no-argument, account-scoped read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Show') and resource ('prepaid credit left on the Evascrape account'), plus the unit (USD). An agent can distinguish this account-balance read from siblings like estimate_cost or job_status without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to call it: 'Check this before starting a large job.' That is actionable timing guidance, though it does not name alternative tools (e.g., estimate_cost) or state when it is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the records of a finished Evascrape job as structured data. Returns the field names and the rows, paged. Ask for a job that has already reached the status "succeeded". With email verification enabled you can pick a variant: "good" for deliverable addresses only, "risk" for catch-all, "bad" for undeliverable. Default "all".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many records to return. Default 1000, maximum 10000. | |
| job_id | Yes | The finished job id. | |
| offset | No | Skip this many records, for paging. Default 0. | |
| variant | No | Which file to read. Default "all". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive) and openWorld. The description adds that it returns field names and rows, paged, and requires a finished succeeded job. It does not mention rate limits, authentication, or other behavioral details. With annotations covering the basics, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then prerequisites, then variant details. Efficient and no wasted words, though could be slightly more structured with bullet points for variants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the key aspects: what it returns (field names and rows, paged), the prerequisite (job must be succeeded), and variant filtering. It doesn't explain return format details like in what structure fields and rows are returned, but no output schema exists, so some description of return values is provided. Missing information about paging limits is in schema. Overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds context about variant meanings (good=deliverable, risk=catch-all, bad=undeliverable) which goes beyond the schema's simple enum descriptions, but the schema already defines the enum and defaults. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: reading the records of a finished job as structured data. It's clear what the tool does, though it doesn't explicitly differentiate from siblings like apollo_export or job_status, which likely deal with jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite: the job must have reached 'succeeded' status, likely directing the agent to use job_status first. It also explains the variant options for email verification filtering, giving guidance on which variant to choose and when. No explicit exclusions beyond the succeeded requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return what a job would cost without starting it or charging anything. Use this before spending on behalf of someone, or when the user asks how much a list will cost.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Which source the job would use. | |
| total_records | Yes | How many records the job would request. Multiple of 100, 100 to 50000. | |
| email_verification | No | Whether real-time email verification would be enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safe-read profile is covered. The description adds a billing-specific reassurance ('without ... charging anything'), which is useful but largely reinforces what the annotations say; it says nothing about estimate staleness, currency, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero padding, with the core guarantee (no start, no charge) front-loaded before the usage conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the safety and usage profile well for a 3-param tool. With no output schema, the description could have stated the shape of the returned cost (units/currency), which is a minor remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter documented (source enum, total_records range/multiple, email_verification boolean), so the baseline of 3 applies. The description adds no parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Return what a job would cost without starting it or charging anything.' The scope negation ('without starting it') implicitly separates it from the sibling job-execution tools, though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete conditions for use: 'before spending on behalf of someone' and 'when the user asks how much a list will cost.' Clear triggering context, but no explicit exclusions or named alternatives (e.g., versus job_status or check_balance).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find local businesses and their contact details from Google Maps: name, address, phone, website, rating, and the email address published on the business website where there is one. Use this for requests like "find 200 dentists in Austin with their emails", "get me restaurants in Berlin with phone numbers" or "build a list of plumbers near Manchester". This is the best starting point for local business prospecting. Costs $12 per 1,000 records from a prepaid balance; you are refunded for anything not delivered. Returns a job id, not the data: poll job_status, then call download.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Google Maps interface language, e.g. "en", "de", "tr". Default "en". | |
| location | Yes | Where to search. A city, region or country. Example: "Austin, Texas". | |
| list_name | No | Name for the export file. Defaults to a name built from the search. | |
| categories | No | Optional extra category filter, comma separated. | |
| min_rating | No | Only include places at or above this Google rating. | |
| skip_closed | No | Skip permanently closed places. Default false. | |
| search_terms | Yes | What kind of business, comma separated. Example: "dentist" or "dentist, orthodontist". | |
| total_records | Yes | Maximum records to collect. Multiple of 100, minimum 100, maximum 50000. This is a ceiling, not a promise. | |
| email_verification | No | Verify every email in real time for an extra $5 per 1,000. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the async contract (returns a job id, not data) and the exact next tools, the cost model ($12 per 1,000 records, refunded for undelivered records), and an optional paid add-on ($5/1,000 for email verification). That is exactly the operational context the readOnlyHint=false / idempotentHint=false annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what is found and the output fields, then usage examples, then cost and async mechanics. Every sentence carries distinct information; no filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and an asynchronous job model, the description supplies precisely the missing pieces: what the call returns (a job id), how to retrieve results (job_status then download), and what it costs. Nothing needed to invoke and complete the workflow is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine parameters and the baseline is 3. The description adds only a marginal clarification that emails come from the business website, which is useful context but not parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find) and resource (local businesses and their contact details) and enumerates the returned fields. It is clearly distinguishable from sibling lead sources like linkedin_leads and apollo_export because it names Google Maps as the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering requests ("find 200 dentists in Austin with their emails", "get me restaurants in Berlin") and positions itself as "the best starting point for local business prospecting", plus the follow-up workflow (poll job_status, then download). It does not explicitly contrast itself with apollo_export or linkedin_leads, so the when-not-to-use case is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an Evascrape job has finished. Call this about 30 seconds after starting a job and then every 20 to 30 seconds. When the status is "succeeded", call download to read the records.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The id returned when the job was started. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context — the polling cadence — which annotations cannot express. It does not mention failure/running states or that the call is cheap to repeat, so it stops short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool does and immediately followed by the operational cadence and the success hand-off. Every sentence earns its place with no repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling tool with no output schema, the description tells the agent when to poll and which status value triggers the next step, which is the essential information. However, it only names the 'succeeded' state, leaving the other possible statuses (running, failed, etc.) undocumented — the one gap an agent would care about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema fully documents job_id. The description implies the id originates from a started job, but that is already stated in the schema, so it adds no syntax or format detail beyond the structured field. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — checking whether an Evascrape job has finished — and names the sibling it hands off to (download) once the job succeeds. An agent can distinguish it from download and the other siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit timing guidance (call ~30 seconds after starting, then every 20-30 seconds) and the exact condition for the next step ('succeeded' → call download). This is a textbook when/when-next instruction with nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a list of people from LinkedIn and Sales Navigator audiences using filters, and get their verified work email addresses. This takes filters, not a LinkedIn URL: job titles, locations, company domains, keywords, industry, company size and revenue range. Use it for requests like "CMOs at SaaS companies in California" or "heads of engineering at companies using Stripe". Costs $9 per 1,000. If you get far fewer results than requested, set include_unverified to true: that single filter is the most common reason a list comes back short. Returns a job id: poll job_status, then download.
| Name | Required | Description | Default |
|---|---|---|---|
| funding | No | Funding stages, e.g. ["seed","series_a"]. | |
| keywords | No | Company keywords to include. | |
| list_name | No | Name for the export file. | |
| locations | No | Regions or countries from Evascrape's list, lowercase. US states end in ", us" (e.g. "california, us"), other regions in ", <country>" (e.g. "england, united kingdom"), or a bare country name ("germany"). Unknown values are rejected. | |
| seniority | No | Seniority levels, e.g. ["c_suite","director","founder"]. | |
| industries | No | Industries to include, lowercase. | |
| job_titles | No | Comma separated job titles to include. Example: "CMO, VP Marketing". | |
| max_revenue | No | Maximum company revenue band, e.g. "50M". | |
| min_revenue | No | Minimum company revenue band, e.g. "1M". | |
| company_sizes | No | Headcount bands, e.g. ["51-100","101-200"]. | |
| total_records | Yes | Maximum leads. Multiple of 100, minimum 100, maximum 50000. | |
| company_domains | No | Comma separated company domains. Domains, not names: "stripe.com", not "Stripe". | |
| exclude_keywords | No | Company keywords to exclude. | |
| exclude_locations | No | Regions or countries to exclude. | |
| email_verification | No | Extra real-time verification for $5 per 1,000. Default false. | |
| exclude_job_titles | No | Comma separated job titles to exclude. | |
| include_unverified | No | Include people whose email is not yet verified. Greatly increases volume. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses pricing ($9 per 1,000, $5 extra for email_verification), the asynchronous job pattern (returns a job id, poll job_status, then download), and a diagnostic tip about the most common cause of short lists. The annotations only mark it non-readonly/open-world/non-idempotent, so this description carries and adds the behavioral weight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then input-shape clarification, examples, cost, a troubleshooting hint, and the return workflow. Every sentence earns its place, though the filter enumeration partly duplicates the schema and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter, no-output-schema, async tool, the description closes all the gaps an agent needs: what it returns (a job id and the poll-then-download follow-up), the cost model, and the key tuning knob. Nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by grouping the filter families and, crucially, explaining the practical consequence of include_unverified ('the most common reason a list comes back short') rather than merely restating its default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (build a list of people from LinkedIn/Sales Navigator) plus the output (verified work emails), and explicitly distinguishes the input style: 'This takes filters, not a LinkedIn URL.' An agent can tell it apart from google_maps_leads and apollo_export without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete triggering examples ('CMOs at SaaS companies in California') and a conditional instruction for shortfalls ('If you get far fewer results than requested, set include_unverified to true'), which is real when-to-use guidance. It stops short of naming when to prefer the sibling audience tools (apollo_export, google_maps_leads) over this one, so routing between the three remains an inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0apollo_exportcheck_balancedownloadestimate_costgoogle_maps_leadsjob_statuslinkedin_leadsScored across 7 tools
The three lead tools clearly target different sources (Google Maps scraping, Apollo URL export, LinkedIn filter-based search), and the support tools (check_balance, job_status, estimate_cost, download) each have a distinct role. No two tools can be reasonably confused for the same task.
All names use snake_case consistently, but the convention varies slightly: source-oriented nouns (google_maps_leads, linkedin_leads, apollo_export) mix with verb-oriented names (check_balance, estimate_cost, download, job_status). Still predictable and readable throughout.
Seven tools is well-scoped for a scraping service: three job-starting sources plus four support operations (balance, status, cost, download). Every tool earns its place with no redundancy.
The job lifecycle (start -> poll -> download), cost estimation, and balance checks are all covered, matching the async job model. Minor gaps like listing/cancelling existing jobs or a job history tool exist but agents can work around them.
Turn Maps queries into lead lists: businesses, phones, websites, and reviews with async job control.
B2B lead generation from Google Maps: search, dedupe and email-enrich businesses. Needs API key.
LeadMagic MCP — wraps the LeadMagic B2B email-finder API (leadmagic.io)
Local business lead extraction with email + phone enrichment from Google Maps.
