Skip to content
Leadbase

Connect AI clients (MCP)

Connect an AI client to the Leadbase Model Context Protocol endpoint.

Open Settings → MCP and copy the server URL or the setup prompt shown there. The panel provides current connection instructions for supported clients, including Claude Code, Codex, Cursor, and a generic MCP configuration.

Keep access scoped

The MCP connection uses the signed-in Leadbase session and its active workspace access. It does not make every workspace or Sheet public. An AI client can only operate within the authorization Leadbase verifies for that session.

Review client configuration before sharing it. The URL is a connection detail; it is not a replacement for access control, and it must not be posted where untrusted users could reuse your authenticated environment.

Find a work email from an AI client

The current MCP catalogue can expose prospects.find_email when the workspace and authorization permit it. The tool accepts either a canonical LinkedIn profile identity or a reviewed person_at_company identity containing first name, last name, and company domain. Add company, title, or two-letter country context when already known. Never ask the model to invent a missing name, domain, or profile.

One call accepts 1-50 identified people. This is a per-call payload, not a Sheet or workflow ceiling. An agent can page a larger Sheet and repeat bounded calls in deterministic order. Create a fresh UUID or ULID for every new ordered batch; reuse the identical input and key only to poll that batch when a result is pending.

Every input returns one ordered state: found, not_found, pending, or failed. A found result includes a professional email and a provider quality label of verified, likely, or unknown. At the documentation date, a found work email consumes one credit. Exact replay, not_found, pending, and failed consume none. Verify the current capability description, workspace policy, and credit state before a material run.

These states describe a lookup, not a sending decision. A found or provider-labelled verified result does not prove current employment, independent identity confirmation, inbox placement, consent, or permission to email. Keep identity review, sending infrastructure, suppression, country and recipient-type rules, and the permitted next action separate.

Find a direct phone number from an AI client

The current MCP catalogue can expose prospects.find_phone for a bounded direct-phone lookup when the workspace and authorization permit it. The contact lookup requires mcp:write; a read-only authorization may not show the tool.

Before a run, a workspace owner or admin must enable Direct phone numbers, acknowledge lawful business use, set the agent batch-credit ceiling, and confirm that the phone route is available for the workspace. Listing the tool is not proof that a request can execute. One MCP call accepts 1-50 identified people. That is a transport boundary per call, not a Sheet or workflow limit. A workflow can process thousands of eligible Sheet rows by paging the table and submitting multiple bounded calls. The enabled status, available credits, rate limits, and configured credit ceiling can still impose a lower live batch or run limit.

For example, 5,000 eligible people require at least 100 calls when every call contains 50 people. Use fewer people when the live workspace limit is lower. Keep a stable row ID, batch sequence, input snapshot, request ID, idempotency key, and terminal result for every person so a large run remains resumable and auditable instead of becoming one opaque bulk request.

Every person requires a canonical https://www.linkedin.com/in/... profile URL. Add the current company, domain, job title, name, or two-letter country code when you already know it; never invent a missing corroborator.

Generate a fresh UUID or ULID for a new batch. If a result is pending, reuse the identical input and idempotency key only to poll that same request. Do not reuse the key with different people or silently start a new paid request after a terminal result.

The result for every input remains in the same order and has one state. The public schema supports the following fields; inspect the values returned by the active route rather than assuming every type will appear:

  • found: includes an E.164 number, a mobile, direct, work, or unknown type, and a verified, likely, or unknown quality label;
  • not_found: the configured lookup did not return a number;
  • pending: poll after the returned delay with the same input and key;
  • failed: a terminal unavailable or technical outcome, not proof that the person has no phone.

At the documentation date, a found phone consumes five credits. Exact replay, not_found, pending, and failed results consume none. The tool response contains the lookup state and result fields, not a credits_consumed field; record cost from the documented rule and the workspace billing record. Check the capability description, workspace policy, and credit state before any run because product terms can change.

These states describe the lookup, not the commercial decision. A found or verified result does not establish that the person is relevant, currently owns the number, will answer, has consented, or may lawfully be called. Keep identity review, suppression, country/channel eligibility, and the permitted next action as separate decisions.