You typed one sentence. Somewhere between that sentence and the answer, an agent chose which of your data connectors to call, decided how much data to pull, and spent credits doing it. You saw none of those three decisions. You saw a result.
The short version: an agent picks a tool by matching your wording against each connected tool’s name and description, with no fixed priority order and no ranking by usage. Search costs 1 credit per batch of up to 25. Revealing an email costs 1 credit. Revealing a phone number costs 5. So the same ten-person shortlist can cost 1 credit or 60, decided entirely by what nobody specified.
This guide is about that gap. Not the theory of it, the mechanics, checked live against Lusha’s own account tools, with real numbers. How tool selection actually works. Where credits leak, with worked examples run in this exact session. A fuzzy-match failure mode worth knowing about specifically. And separate playbooks for sellers and RevOps, because the failure modes are different at each end.
Every Lusha figure on this page was pulled live via Lusha’s MCP tools in this session. Names are masked to initials, phone numbers withheld, per standard privacy practice. Every claim about how Claude’s tool selection works is sourced to Anthropic’s own documentation, linked inline.
Part 1: How an agent actually chooses a tool
Tool descriptions are the entire interface
When you connect a data provider to an AI agent, you’re not installing software in the usual sense. You’re adding a set of function definitions, each with a name and a short block of description text. Per Anthropic’s documentation, tool selection works by matching your request against those names and descriptions.
That’s the whole mechanism. There’s no fixed priority order. No ranking by install date, contract size, or how often you’ve used something. No paid placement. Every request is a fresh match.
Which produces a consequence worth naming: a well-described tool gets selected more reliably than a vaguely described one, independent of how good the underlying data actually is. Description quality and data quality are separate variables, and only one of them drives selection.
Selection gets harder as your tool count grows, and Anthropic has published the numbers
Anthropic’s own engineering documentation states tool-selection accuracy “degrades once you exceed 30-50 available tools.” In their internal evaluations, adding a tool-search capability that loads tool definitions on demand instead of upfront raised MCP evaluation accuracy from 49% to 74% on Claude Opus 4, and from 79.5% to 88.1% on Opus 4.5. Read the other direction: without that capability, in a large tool set, correct tool selection can sit well below 80%, and in some configurations under 50%.
That’s not a hypothetical. If you’re running Lusha alongside Apollo, ZoomInfo, a CRM connector, and a couple of plugins, you can cross 30-50 available tools faster than it sounds. The more tools live in a session, the more selection depends on description quality, and the more a vague prompt leaves to chance.
Plugins and connectors are two different things, and the gap between them is invisible
Worth being precise about, because it’s a real, documented failure mode people run into. A plugin bundles instructions and workflow skills. A connector is the authenticated pipe to a vendor’s actual data. Anthropic’s own documentation treats them as separate: “Plugins add role-specific intelligence and workflows to Claude… Connectors give Claude access to external tools… Plugins use connectors to access data, they work together.”
A plugin’s skill can reference a specific tool by name. If the connector behind that tool was never authenticated for your account, that reference doesn’t resolve to anything, the skill is loaded, the instructions are in context, but there’s no live tool for it to call. Anthropic’s own diagnostic guidance for this exact situation: “Claude knows how to do the task but can’t reach the system that holds the information… you’re missing a connector.” Multiple developers have documented this same gap independently on Anthropic’s public issue tracker.
The practical takeaway: installing a plugin is not the same as connecting its data source. If a workflow isn’t returning what you expect, check whether the underlying connector is actually authenticated before assuming the prompt is wrong.
Why you can’t reliably predict which tool gets picked
Suppose you have several data connectors live and a prompt any of them could plausibly answer. Which one runs? Nobody can tell you reliably in advance, not the documentation, not the vendor, and an agent asked afterward to explain its own choice will produce a plausible-sounding reconstruction, which isn’t the same as a reliable account of the actual mechanism.
That’s clarifying rather than discouraging, because it tells you exactly where to intervene:
- Several connectors live, vague prompt → non-deterministic, and you won’t see which one charged you.
- Several connectors live, tool named explicitly → deterministic.
- One connector live for the task → deterministic by construction.
Connectors are enabled per conversation, not permanently. Turning off what you don’t need for a given task removes the decision entirely instead of trying to win it. That’s the single highest-leverage habit in this guide, and it takes one click.
Part 2: Where your credits actually go
Credit waste in agent workflows is rarely one dramatic mistake. It’s usually a default nobody changed, run across a batch.
The real pricing, pulled live from account_usage
Querying Lusha’s account tool returns the account’s actual, current per-action pricing map, at no cost to check. Here’s what came back in this session:
| Action | Cost |
| Company search | 1 credit per batch of up to 25 |
| Contact search | 1 credit per batch of up to 25 |
| Reveal email | 1 credit per contact |
| Reveal phone | 5 credits per contact |
| Reveal company premium field | 1 credit per field |
| Lookalike match | 1 credit per 5 results |
| View signal | 1 credit per company or contact |
Worth correcting a common assumption directly: search is cheap, batched into groups of 25, but it isn’t free. The real leverage isn’t a free identify step, it’s that search costs a fraction of what reveal costs, so a wasted search is a rounding error and a wasted reveal isn’t.
Worked example, run live in this session
We searched Snowflake for director and VP-level sales contacts. The search itself, returning 10 results out of 2,635 matches, cost 1 credit. Each result came back with a per-field reveal cost attached before anything was spent:
| Contact | Title | Email reveal | Phone reveal |
| D.R. | Head of Sales Development | 0 credits | 5 credits |
| C.M. | Director of Sales Development | 1 credit | 5 credits |
| A.F. | Global Account Manager | 0 credits | 0 credits |
| R.W. | Director of Sales Development | 0 credits | 0 credits |
Four of ten returned, individually masked. Live result, this session.
Worth flagging, since it’s a real nuance the standard pricing table doesn’t show: per-contact reveal cost isn’t perfectly uniform. The majority of contacts priced at the standard 1 credit email and 5 credit phone, but a few showed 0 credits on one or both fields in this session. We haven’t confirmed the mechanism behind that with engineering, so treat it as an observation, not an explanation. It may relate to prior reveals on those specific records, or to something else in the pricing logic. The standard rate is the one to budget against. The per-contact number is the one to check before you reveal, since it can come in lower than expected, and occasionally higher.
Here’s the arithmetic that decides your bill. Ten contacts, phone only at the standard rate, is 50 credits. Email and phone on all ten is 60. Email only is 10. And the search that produced the list was 1. Same list, same task, a 60x spread from top to bottom, decided entirely by whether anyone specified which fields to reveal.
The default-on trap
Company and contact lookups accept an enrich parameter. When true, the response bundles premium fields into the search itself and spends reveal credits immediately. When false, you get the preview, names, titles, firmographics, and the per-field cost map, with no reveal credits charged. Confirmed live: a company preview search with enrich set to false returned full firmographic detail plus a reveal-cost breakdown, for 1 credit, the search cost alone, no reveal credits attached.
The default varies by tool and by account setting, which is exactly the reason to check rather than assume. An agent told simply to “pull the contacts at these accounts,” with nobody specifying otherwise, may reveal every field on every result. The fix is one instruction: preview first, reveal second. Ask for the search, read the titles, pick a shortlist, then reveal only that shortlist and only the fields you’ll actually use.
A failure mode worth knowing about specifically: fuzzy matching on a bad query
Here’s something we found by deliberately testing it, not by reading about it. We searched for a completely fabricated company name, a string designed to match nothing real. Rather than an empty result or a typed “not found,” the search returned 156 total matches, ten real people at a real, existing company, charged at the standard 1 credit for the search.
What happened: the fabricated string happened to contain a common English word as a substring, and the search matched it against a real company whose name contains that same word, entirely unrelated to what was actually intended. The result set looked completely normal, real names, real titles, real locations, nothing marking it as a probable mismatch.
This is a more useful thing to know than a clean “invalid input returns an error” story, because it’s the opposite of reassuring: a bad or malformed query doesn’t reliably fail loudly, it can succeed quietly against the wrong target, and a confident-looking result set is not the same as the right result set. Before trusting a search result on an account or company you’re not already familiar with, it’s worth a quick sanity check, does the domain, location, and size actually match what you expected, rather than assuming a returned result is automatically the intended one.
Part 3: Four checks, under a minute, almost no credits
Check 1: “List the data connectors active in this conversation, by name”
Not “what can you do.” Ask for the specific list. An installed plugin is not the same as a connected connector, as covered in Part 1, and the two can drift apart without any visible warning. If the list is shorter than expected, fix that before running anything.
Check 2: “What’s my current credit balance and rate limit?”
Lusha’s account tool answers this directly, at no cost: total credits, used, remaining, and rate-limit headroom at the minute, hour, and day level, each with a reset time. Not every connector exposes this. Where one doesn’t, treat batch operations as unmetered until you’ve run a single record and checked the billing field yourself.
Check 3: “What will this specific operation cost before I run it?”
The difference between a balance and a quote. A balance tells you what’s left. A quote tells you what the next action costs. The per-field reveal cost attached to each search result, confirmed live above, is a quote. If you can get a quote, you can budget. If you can only get a balance, you can only audit after the fact.
Check 4: Search for something you know doesn’t exist
Run a deliberately fabricated query once, on any connector, before trusting it with real work. Read the response shape carefully. A typed, explicit error is the clean outcome. An empty result is ambiguous but at least honest. A confident, populated result set for a search that should have matched nothing, the outcome we found live in Part 2, is the one to actually worry about, because nothing in the output tells you it happened.
Part 4: If you’re a seller
Name the tool in the prompt. Three words. “Use Lusha to find verified contacts at Acme” instead of “find me contacts at Acme.” Costs nothing, makes the call deterministic.
Be specific, and selection narrows itself. A vague request could plausibly be answered by any connected data tool. A specific one, naming a signal, a filter, a field, can only be answered by a tool that actually has that capability, which eliminates candidates before selection even happens.
Preview before you reveal. Search first, read titles and fit, shortlist, then reveal. On the live search above, that was the difference between 1 credit and 60.
Reveal phone only when someone will actually dial. Phone reveal runs 5x email reveal at the standard rate. Pulling mobile numbers for contacts nobody’s calling is the clearest line-item waste in agent-driven prospecting.
Sanity-check a result before you trust it on an unfamiliar target. Especially for a company or query you don’t already know well, given what the fuzzy-match test in Part 2 found.
Part 5: If you’re in RevOps
Standardize the prompt, not the person. If five reps phrase the same workflow five different ways, they may be routing to different tools for what should be an identical task, producing inconsistent data in the same CRM depending on who typed what. Ship an explicit-naming version as a saved template.
Audit for the plugin-without-connector gap specifically. If your team approved a plugin’s skills without confirming its connector is actually authenticated, you’ve shipped a workflow referencing tools nobody can call, and per Part 1, the failure is invisible until someone hits it.
Set a preview-first policy for batch work. Any enrichment past a threshold, 25 is reasonable, runs preview-only first, with reveal limited to an approved shortlist. This is the single highest-value policy here, since uncontrolled batch reveal is where credits disappear fastest.
Make field selection explicit in shared templates. Don’t let a default decide. Email-only for sequencing workflows, phone only for calling workflows, stated directly in the prompt template.
Curate connectors at the org level. Connectors are enabled org-wide from Organization settings > Connectors. Members authenticate individually but choose from a list you’ve already narrowed, the org-level version of turning off what you don’t need, done once for everyone.
Authorize centrally where it’s available. Enterprise-managed auth, in beta for Team and Enterprise plans, authorizes a connector through your identity provider so the team inherits access on first login, and revoking identity-provider access revokes connector access at the same time, rather than a stale token lingering after someone leaves.
Restrict at the tool level where it counts. Team and Enterprise owners can disable specific tool calls within a connector rather than the whole thing, a real distinction if a connector offers both read and write actions and only the read side should be available broadly.
Know the stricter layer exists for developer teams. Claude Code supports a managed configuration that deploys a fixed, admin-defined set of servers and can suppress individually added connectors, tighter than standard connector settings.
Should you add another connector?
Not automatically better or worse, a trade-off worth making on purpose.
The case for running more than one: different tools do different jobs well. Verified prospecting and real-time signals is a different discipline from sequence automation. Forcing one tool to cover both usually means it’s adequate at the second job. Real GTM stacks tend to work this way already, one tool per distinct job, which is a reasonable default rather than a sign of a messy stack.
The case against: every connector with overlapping capability adds the exact ambiguity this guide is about, more chances for a vague request to land somewhere unintended, more surface to govern, and duplicated spend that’s structurally hard to see.
The actual question: does the new connector do something none of your existing ones do? If it’s distinct, adding it is additive. If it largely overlaps with something you already run, you’re not adding capability, you’re adding a coin flip, unless the plan is to replace the old one rather than run both indefinitely.
Quick reference
- Tool selection matches your wording against each tool’s name and description, no fixed order, not fully predictable in advance
- Accuracy degrades past 30-50 available tools, per Anthropic’s published evaluations
- Search costs credits too, batched cheaply, but not free, check the real pricing rather than assuming
- Ten contacts: 1 credit to search, 10 to reveal email, 60 to reveal everything
- A confident, populated result can still be the wrong result, verify unfamiliar matches before trusting them
- Preview first, reveal second, and reveal only the fields you’ll use
- Name the tool explicitly for any request more than one connector could plausibly answer
- Disable connectors you don’t need for a given conversation, highest leverage, one click
- Installed plugin is not a connected connector, audit the pairing, especially at the team level
- Admins: curate connectors org-wide, use centralized auth where available, restrict at the tool level when it counts
FAQ
How does an AI agent decide which data connector to use?
By matching your request against the name and description of every tool actually connected in that session. No fixed priority order, no ranking by usage, no paid placement.
Does adding more connectors make tool selection less accurate?
Yes. Anthropic’s engineering documentation states selection accuracy degrades once you exceed 30-50 available tools, and their published evaluations show meaningful accuracy gaps in large tool sets. Running several data connectors plus a CRM connector plus plugins crosses that threshold faster than it sounds.
Is search really free?
No. Per Lusha’s own account pricing, search costs 1 credit per batch of up to 25 results, cheap relative to reveal, but not zero. Check the actual pricing map for your account rather than assuming.
What’s the difference between preview and reveal?
Preview returns who someone is, name, title, department, company data, plus a per-field cost map for their contact details. Reveal returns the actual email and phone and charges for it. Preview is how you qualify before you pay.
How many credits does a contact reveal cost?
At the standard rate confirmed live in this session: 1 credit for an email, 5 credits for a phone number. So a full reveal on one contact is 6 credits, and on a ten-person shortlist it’s 60, against 1 credit for the search that produced the list.
Can a search return confident results for something that shouldn’t match anything?
Yes, and it’s worth planning for. In a live test, a deliberately fabricated company name matched a real, unrelated company via substring matching and returned a full, normal-looking result set. Nothing in the output flagged it as a likely mismatch. Sanity-check results against an unfamiliar target before trusting them.
I installed a plugin. Is its connector automatically connected?
Not necessarily. Plugins and connectors are separate systems per Anthropic’s own documentation. A plugin’s skills can reference a connector’s tools by name without that connector ever being authenticated, and the gap doesn’t surface until a skill tries to use it.
Can two people on the same team get different results from an identical-sounding request?
Yes, if they have different connectors enabled or phrase the request differently enough to match a different tool’s description. Standardizing phrasing at the template level is the fix.
Does this work differently in Claude Code or the API versus claude.ai?
The core selection mechanism is the same everywhere. Claude Code supports a stricter, admin-managed configuration that can suppress individually added connectors, tighter control than standard claude.ai connector settings.
Go deeper
- claude.com/connectors/lusha, install Lusha directly from Claude
- www.lusha.com/campus/plays, ready-to-run prompts for verified prospecting and signals
- www.lusha.com/campus/ai-connectors, every way to run Lusha inside an AI agent
- www.lusha.com/campus/signals, how buying signals work and what triggers them
Want a connector that shows you the cost before you spend it? Start for free with Lusha
