Blog · MCP
How to find customers from Claude, using an MCP server
An assistant that can only talk is a good writer and a poor colleague. The Model Context Protocol changes that: it lets Claude, Cursor or any compatible client call real tools on real data, then reason about what comes back. For go-to-market work that shift is larger than it sounds, because the useful question was never “write me a cold email”. It was “who should I be talking to today, and why them”.
This is a practical walk through what that looks like in a sales context — what it genuinely does, where it stops, and how to connect one in about three minutes.
What MCP actually is, in one paragraph
MCP is a small protocol that lets an assistant discover and call tools exposed by a server. The server advertises what it can do; the assistant decides when to use it and what to do with the answer. That is the whole idea. Its consequence is that the assistant stops guessing from training data and starts reading something current — your inbox, your database, a live search — with the reasoning happening on top of facts instead of instead of them.
The practical difference is easy to feel. Ask a plain assistant “who wants to buy a CRM right now” and you get a plausible-sounding paragraph about buyer personas. Ask one wired to a tool that reads live public posts and you get names, dates and links you can open.
Why it matters more for sales than for most jobs
Prospecting is an unusually bad fit for a chat window and an unusually good fit for a tool call. The work is not writing — it is finding, judging and prioritising, and only then writing. Three of those four steps need current data that no model carries.
There is also a friction argument, and it is the honest reason this approach converts. Most prospecting tools open with a form: your product, your offer, your ideal customer, your competitors, your tone. Seven fields before you see anything at all. A great many people fill in two and leave. In an assistant there is no form — you describe your business in a sentence, because you were going to type a sentence anyway.
What it does not do
Three limits worth stating before the setup, because the category attracts a lot of overclaiming.
It does not send anything. An assistant that publishes on your behalf is a liability, not a feature — you would be putting your account and your reputation behind text you have not read. A drafted reply that you edit and post yourself is slower by thirty seconds and better in every other way.
It does not invent demand. If nobody in your market posts publicly, no tool will find them, and you want to learn that in an afternoon rather than after a year of subscriptions. Check a public index before you pay anyone anything.
It does not replace judgement. A score of 88 means a post has the shape of buying intent. Whether that person is worth your next hour is still your call, and it always will be.
Connecting one, concretely
The steps below use Askline’s MCP server because it is the one I can describe precisely, but the shape is the same for any of them.
First, decide whether you need a key at all. Some servers expose read-only tools to anyone. Askline’s demand_index and score_post work with no account: you can read real, dated posts from people asking to buy software, and score any post you paste in. That is enough to judge whether the data is worth anything before you sign up for it — which is the right order.
Then add the server to your client. In most clients that is a short block of configuration:
{
"mcpServers": {
"askline": {
"url": "https://askline.app/mcp",
"headers": { "Authorization": "Bearer ask_live_your_key_here" }
}
}
}
Then ask in plain language. You do not call tools by name; the assistant picks. These are the sentences that do real work:
- “Who is asking for a CRM on X right now?”
- “Is this post worth answering? Our CRM costs $400 a month for features nobody uses.”
- “Find people who want what I sell — I make invoicing software for freelancers.”
- “Show me the contacts I have not answered yet, highest score first.”
The last two need a key, because they run a live search against your own offer and read your own inbox.
The part that makes it worth doing
Everything above is mechanics. The reason to bother is that the assistant can now chain steps you would otherwise do by hand across four tabs. “Find people leaving Brand24, score them, and draft a reply to the three best in my voice” is one sentence and one wait, not an afternoon.
And because the result is data rather than prose, you can push on it: why did this one score 91? Which of these is actually a person and not a brand account? Show me the original post. A summary cannot answer follow-ups. A tool call can.
How to judge one of these servers
The category is new and thin on evidence, so a short checklist. Does it show sources? A claim that “40 people want your product” is worth nothing without links you can open in thirty seconds. Does it distinguish stated intent from engagement? Somebody visiting your profile is not somebody writing “I need to replace this thing”. Does it tell you when it does not know? A tool that returns a confident number for every question is not measuring, it is guessing.
Askline’s answer to the first one is that every post carries its original link, and the demand index is public so you can audit it without an account. The second is in the difference between a mention and a buyer, and the tool-by-tool version is in the comparisons.
Where to start
Point your assistant at a public tool first and ask it something you already know the answer to. If what comes back is checkable, keep going; if it is not, you have learned something cheap. The setup page has the configuration and the four tools, two of which need nothing from you.
The underlying method — the six shapes of buying intent, how to score them, how to reply without reading as an advert — is written up in the guide to finding buyers on X. The protocol is new. The work it automates is not.