MCP server for sales: build lists and get verified mobiles in one flow
Updated
An MCP server lets you build a prospect list and enrich it with verified mobile numbers from inside ChatGPT or Claude, in plain language, without opening a separate tool. The useful ones return the phone number and the evidence behind it: line type, verification date, and whether the line is attached to the person named.
The category is young and most of what is written about it is vendor copy. The three questions that actually decide whether one is usable in a sales team are: what a single call costs you in credits, whether spend can be capped per user, and whether the connection is per-user or a shared key.
What this replaces, and what it does not
It replaces the part of list building that is clicking: opening a database UI, setting filters, exporting a CSV, uploading it to an enrichment tool, downloading the result, pushing it to the CRM.
It does not replace your CRM, and it should not try to. The pattern that works is that the assistant does discovery and enrichment, and your CRM stays the system of record. An MCP that writes directly into your CRM without a review step is a data quality incident waiting for a slow afternoon.
It also does not replace a batch pipeline. These servers are built for lookups in the range of one to a few hundred records. If you are refreshing fifty thousand contacts monthly, that is a job for an API and a schedule, not for a conversation.
What a request actually looks like
In practice you write something like:
Find the heads of sales at French SaaS companies between 50 and 200 employees that are hiring SDRs, then get me verified mobiles for the ones in Paris.
Underneath, that resolves to a sequence of tool calls. On Listar's server the sequence is:
| Step | Tool | What it does |
|---|---|---|
| 1 | search_people, or search_companies then find_company_contacts |
Finds the matching people, or the companies and then their decision makers |
| 2 | get_result |
Collects results from searches that run in parallel |
| 3 | enrich_list or enrich_person |
Returns phone and email for the saved list |
| 4 | get_credit_balance |
Reports what remains before you commit to the next batch |
Two details matter more than the prompt wording.
Anchoring. A trade name is the weakest possible identifier for a company. An establishment registration number or an official website domain is far stronger, and for France every establishment's number is public. A server that lets you pass that identifier will beat one that only takes a company name, regardless of database size.
Parallelism. Searches take time. A server that makes you wait for each one serially will feel broken on a list of thirty companies. The pattern to look for is launching searches without waiting, then collecting them together.
The three questions that decide usability
What does a call cost, and can you cap it?
This is the question buyers ask first and vendor pages answer last.
An assistant that can spend credits is an assistant that can spend your month in one enthusiastic afternoon. What you need is a confirmation step before a billable batch, a visible balance the assistant can read, and ideally a per-user ceiling enforced on the server rather than in a prompt. A limit that lives in an instruction is not a limit.
Ask specifically: does a search cost credits, or only an enrichment, and is a call that delivers nothing free? What you want is a price stated per result before the call, and nothing billed when nothing is delivered.
Is the connection per-user or a shared key?
A shared API key pasted into a team's configuration means every action is attributed to the key, not the person. No audit trail, no per-seat limit, and no way to revoke one rep's access without rotating everyone's.
Per-user authentication costs more to set up and is the only version that survives contact with a real sales team.
What happens when the data is wrong?
Any enrichment will return a wrong number eventually. What matters is whether the server gives you a way to report it that feeds back into the data, and whether you are charged for it. Listar exposes a report_result_issue call for exactly that, and a bounced email or a wrong-company number reported through it is how the waterfall gets corrected rather than repeating the error next quarter.
The security question nobody puts in the brochure
An MCP server is a tool an assistant can call based on text it has read. If that text can come from an untrusted source, a document, a web page, an email in a thread, then that source can attempt to influence which tools get called.
The practical defences are unglamorous: enrichment behind an explicit confirmation, a credit ceiling enforced server-side, no write access to the CRM from the assistant, and per-user auth so that anything that does happen is attributable.
Ask the vendor which of those four they enforce. The answer tends to be short and informative.
What to look for in the response payload
This is where most servers in this category fall short, and it is the difference between a phone number and a usable phone number.
A good payload returns, per number:
- The number itself, in international format
- Line type: mobile, landline or VoIP
- Whether the line is attached to the person named on the record
- The date each of those was last established
Without the attachment field and the dates, you have a string that looks like a phone number. Your rep finds out which kind it was on the call.
Where Listar stands
Listar's server is published in the official ChatGPT app directory, and runs in Claude and other MCP clients.
Coverage is complete for France, where companies are resolved against the official registers rather than scraped listings, and partial elsewhere, with the United States, the United Kingdom and India being where coverage is actively expanding. Being precise about that is more useful to you than a global claim.
Every delivered mobile carries the verification Listar applies before delivery: a waterfall across more than 35 sources for coverage, then four verification layers including an attachment check used to confirm the line is in use and tied to the right person.
Searches and enrichments are billed in credits, per result delivered, at prices each tool states before it is called: 5 cents per person a role search returns, 2 cents per company a company search returns, and a phone or an email only when one is found. Nothing is billed when nothing is delivered, and the assistant can read the balance at any time. A call that cannot be paid returns an explicit insufficient-credit response rather than failing silently, which matters when an assistant is working through a list unattended.
Measured on our own data: 95% of delivered mobiles were confirmed attached to the right person, from 10,000 real calls across 100 files of 100 numbers each, between May and September 2026. Internal, not audited, denominator is numbers delivered.
FAQ
Is there an MCP server that returns verified mobile numbers? Yes. What varies is what verified means and whether the payload tells you. Ask whether the response includes the line type and an attachment field, because a number without both is not meaningfully verified.
Can I cap what an assistant spends on enrichment? On a well-built server, yes, through a confirmation step before billable calls and a server-side ceiling. Treat a vendor that offers only prompt-level instructions as uncapped.
How many records can I enrich per call? Most servers in this category are designed for small batches, from a single contact to a few hundred. For continuous large-volume refresh, use an API and a schedule instead.
Does this work in Claude as well as ChatGPT? Yes. MCP is a shared protocol, so a server published for one client works in others that support it.
What is the difference between this and a Clay enrichment waterfall? Clay is a platform you build a workflow in, which is powerful and assumes someone on the team enjoys building workflows. An MCP server answers a sentence. The platform wins for repeatable high-volume pipelines, the server wins for the ad-hoc lookups that make up most of a rep's day.
Should the assistant write results straight into my CRM? We would not. Keep the CRM as the system of record and put a human review step in between, at least until you have watched the enrichment behave for a few weeks.