Connect Lusha to Claude: Score ICP fit and track intent signals

If your team needs to connect Lusha to Claude to score ICP fit, track buyer intent signals, or automate bulk contact enrichment, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Lusha's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on /connect-lusha-to-chatgpt-prospect-leads-and-enrich-contact-info/ or explore our broader architectural overview on /connect-lusha-to-ai-agents-automate-lead-search-and-sales-intel/.

Giving a Large Language Model (LLM) read and write access to a premium B2B intelligence platform like Lusha is an engineering challenge. You have to handle strict API token lifecycles, map massive firmographic JSON schemas to MCP tool definitions, and deal with Lusha's complex credit billing system. Every time Lusha updates an endpoint or deprecates a legacy V2 resource, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Lusha, connect it natively to Claude Desktop, and execute complex sales intelligence workflows using natural language.

The Engineering Reality of the Lusha API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against Lusha's APIs is painful. You are not just integrating a simple CRUD app - you are interfacing with a massive data warehouse that charges per field revealed and requires strict polling patterns.

If you decide to build a custom MCP server for Lusha, you own the entire API lifecycle. Here are the specific challenges you will face:

Financial Risk via Endpoint Misrouting Lusha treats its API as a metered utility. Calling lusha_contacts_search costs credits per successful result, but calling lusha_contacts_search_and_enrich charges for the search plus per revealed field (email, phone, etc.). If you build a naive MCP server that exposes all endpoints equally, an LLM might loop over an enrichment endpoint to simply find names, draining thousands of dollars in credits in minutes. Your MCP server must enforce strict schema descriptions that explain the exact financial cost of invoking specific tools to the model.

Asynchronous Polling and Job States Lusha does not return bulk enrichment data synchronously. When you call the lusha_contacts_enrich endpoint with up to 100 contact IDs, the API returns a job object. Your system must then poll the get_single_lusha_contact_enrich_job_by_id endpoint. Lusha strictly enforces a retryAfter timer. If an LLM tries to continuously check the job status without respecting the timer, it will hit rate limits. Building this logic into a custom server requires maintaining state across multiple LLM tool calls.

Strict Identifier Types and Filter Dependencies Lusha's scoring and filtering endpoints are highly rigid. For example, lusha_companies_signal_score requires exactly one identifier type per company: id, domain, name, or email. If the LLM passes multiple, the request fails. Furthermore, prospecting filters like locations require the exact valid string values retrieved from a secondary endpoint (get_single_lusha_company_prospecting_filter_by_id). An LLM cannot simply guess "New York" - it must fetch the valid filter ID first. Your MCP server must orchestrate these dependency chains.

A note on rate limits: When an upstream API like Lusha returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec, but the caller (Claude) is responsible for executing the retry and backoff logic. Truto does not absorb or automatically retry rate-limited requests.

Step 1: Create the Lusha MCP Server

Instead of building a JSON-RPC 2.0 server from scratch, you can use Truto to dynamically generate an MCP server scoped specifically to your connected Lusha account.

Truto creates MCP tools dynamically from the integration's documented API schema. There are no pre-compiled tool wrappers - if a Lusha endpoint is documented, it is available as a callable tool. You can create this server either through the Truto UI or programmatically via the API.

Method A: Via the Truto UI

1. Log into your Truto dashboard and navigate to your connected Lusha account under Integrated Accounts.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure your server. You can limit the server to specific tags (like prospecting or signals) or specific HTTP methods (like read only) to prevent accidental credit spend.
5. Click Create and copy the generated MCP Server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method B: Via the Truto API

If you are provisioning AI agents programmatically, you can generate the MCP server via a REST call. The response will contain the secure URL you need to connect your client.

// POST /integrated-account/{integrated_account_id}/mcp
const response = await fetch('https://api.truto.one/integrated-account/lusha-account-id/mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_TOKEN',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "Lusha Sales Intel Agent",
    config: {
      methods: ["read", "write", "custom"],
      tags: ["contacts", "companies", "signals"]
    },
    expires_at: "2026-12-31T23:59:59Z"
  })
});
 
const mcpServer = await response.json();
console.log(mcpServer.url); // Pass this URL to your MCP client

Step 2: Connect the MCP Server to Claude

Once you have your Truto MCP URL, connecting it to Claude takes seconds. Because the token is embedded in the URL, no additional authentication configuration is required on the client side.

Method A: Via the Claude Desktop UI

If you are using a standard UI client that supports remote MCP connections (like ChatGPT's Custom Connectors or Claude's UI):

1. Open Claude Desktop.
2. Navigate to Settings -> Integrations -> Add MCP Server.
3. Give the server a descriptive name (e.g., "Lusha Intelligence").
4. Paste the Truto MCP URL into the connection field and click Add.
5. Claude will instantly handshake with the server, returning a list of available Lusha tools.

Method B: Via the Claude Config File

If you are running Claude Desktop natively and want to configure the server via the claude_desktop_config.json file, use the official Server-Sent Events (SSE) client wrapper provided by the Model Context Protocol team.

Edit your configuration file (located at ~/Library/Application Support/Claude/claude_desktop_config.json on Mac, or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "lusha_intel": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_TRUTO_TOKEN"
      ]
    }
  }
}

Restart Claude Desktop. The Lusha tools will now appear as accessible capabilities in your workspace.

Lusha Hero Tools for Claude

By leveraging the integration's schema, Truto exposes dozens of Lusha endpoints as tools. Here are the highest-leverage operations for building B2B intelligence agents.

lusha_contacts_search_and_enrich

This tool allows the agent to find contacts by identifier (LinkedIn URL, email, or name plus company) and reveal their full data in a single call. This bypasses the need for two separate search and enrich steps, but costs credits for both the search and every revealed premium field.

"Find the VP of Engineering at Acme Corp and reveal their direct dial and email using the search and enrich tool."

list_all_lusha_account_usage

Because Lusha is a metered API, an AI agent should always check the credit balance before executing a bulk prospecting loop. This tool returns the current snapshot of credit balances, rate limits, and plan details.

"Check our current Lusha credit balance and rate limits before starting the enrichment batch for the 500 target accounts."

lusha_companies_signals

This tool pulls active intent signals (hiring, headcount changes, web traffic, IT spend, news) for up to 100 company IDs. The LLM can specify a startDate to restrict the search. Credits are only charged per matched signal.

"Pull all hiring and intent signals for the attached list of company IDs over the last 30 days."

lusha_contacts_icp_fit_score

Instead of asking the LLM to guess if a lead is good, use this tool to score 1-100 contacts against up to 3 active Target Profiles (ICPs) configured in your Lusha dashboard. It returns a definitive score from 0 to 1.

"Score this list of 50 contact IDs against our active Target Profiles to find the best ICP matches. Return only contacts with a score above 0.8."

lusha_companies_lookalikes

When your agent finds a high-intent account, it can use this tool to find similar companies based on domains or LinkedIn URLs. It returns a dedupeSessionId so the agent can paginate for more results without retrieving repeats.

"Find 20 lookalike companies based on the domain 'stripe.com'. Keep track of the session ID in case we need to expand the list."

get_single_lusha_contact_enrich_job_by_id

When running async batch enrichments via lusha_contacts_enrich, Lusha returns a job ID instead of immediate data. The agent uses this tool to poll the job status. The schema explicitly instructs the agent to respect the retryAfter field before polling again.

"Check the status of enrichment job 88472. If it is still processing, tell me exactly how long you will wait before retrying based on the retryAfter parameter."

lusha_companies_website_visits

This powerful beta endpoint ranks companies that visited your tracked domains within a specific date range. It provides a direct line between anonymous web traffic and firmographic data.

"Show me which companies have visited our pricing page domain in the last week and rank them by visit metrics."

To view the complete inventory of available Lusha operations, schemas, and credit costs, check out the Lusha integration page.

Workflows in Action

Workflow 1: Account Intent & Lookalike Expansion

In this scenario, a sales development representative asks Claude to build a prioritized target list based on active buying signals, expand that list with lookalikes, and score the results against the company's ideal customer profile.

"Find which companies on my target list are showing active IT spend intent signals. Take the ones showing intent, find 10 lookalike companies for each, and then score all the lookalikes against our ICP profiles. Give me a table of the top matches."

sequenceDiagram
    participant User as User
    participant Claude as "Claude Desktop"
    participant Truto as "Truto MCP"
    participant Lusha as "Lusha API"

    User->>Claude: "Find companies showing intent,<br>get lookalikes, and score them."
    Claude->>Truto: call lusha_companies_signals
    Truto->>Lusha: GET /signals
    Lusha-->>Truto: Intent events
    Truto-->>Claude: JSON response
    Claude->>Truto: call lusha_companies_lookalikes
    Truto->>Lusha: POST /lookalikes
    Lusha-->>Truto: Lookalike companies
    Truto-->>Claude: JSON response
    Claude->>Truto: call lusha_companies_icp_fit_score
    Truto->>Lusha: POST /icp_fit_score
    Lusha-->>Truto: Scored results
    Truto-->>Claude: JSON response
    Claude-->>User: Summarized prioritized target list

1. Signal Extraction: Claude parses the user's target list and calls lusha_companies_signals with the company IDs, requesting only the intent signal type.
2. Lookalike Generation: For the companies that returned positive intent hits, Claude takes their domains and passes them to lusha_companies_lookalikes as seeds, retrieving a fresh batch of similar accounts.
3. ICP Scoring: Claude takes the IDs of the newly discovered lookalikes and passes them to lusha_companies_icp_fit_score to see how well they match the company's pre-configured target profiles.
4. Formatting: Claude presents the final, highly-qualified list of net-new accounts to the user in a Markdown table, filtered by the highest fit scores.

Workflow 2: Credit-Aware Bulk Enrichment

Because Lusha is expensive, agents must operate with financial guardrails. In this workflow, the user asks Claude to enrich a large list of contacts, but Claude proactively checks the budget and handles the complex asynchronous polling required by Lusha's bulk API.

"Check our Lusha credit balance. If we have more than 500 credits, initiate a bulk enrichment for this list of 100 contact IDs. Monitor the job until it finishes and return the revealed emails."

sequenceDiagram
    participant User as User
    participant Claude as "Claude Desktop"
    participant Truto as "Truto MCP"

    User->>Claude: "Check credits, then enrich<br>these 100 contacts."
    Claude->>Truto: call list_all_lusha_account_usage
    Truto-->>Claude: Credits remaining
    Claude->>Truto: call lusha_contacts_enrich
    Truto-->>Claude: Job ID & retryAfter
    loop Every retryAfter seconds
        Claude->>Truto: call get_single_lusha_contact_enrich_job_by_id
        Truto-->>Claude: Job Status (Processing)
    end
    Claude->>Truto: call get_single_lusha_contact_enrich_job_by_id
    Truto-->>Claude: Job Status (Complete) & Data
    Claude-->>User: Enrichment complete,<br>emails provided

1. Credit Check: Claude calls list_all_lusha_account_usage to verify the account has sufficient reveal_contact credits to process the batch.
2. Job Initialization: Claude calls lusha_contacts_enrich with the 100 contact IDs. The tool returns a jobId and a retryAfter integer.
3. Polling Loop: Claude pauses its execution based on the retryAfter value, then calls get_single_lusha_contact_enrich_job_by_id. It repeats this loop until the API returns a status of completed.
4. Data Delivery: Claude parses the final enriched dataset, extracts the requested email addresses, and returns them to the user.

Security and Access Control

When deploying MCP servers connected to sensitive datasets like Lusha, controlling what the LLM can do is critical. Truto provides several mechanisms to lock down your MCP URLs:

• Method Filtering: You can restrict an MCP server to read-only operations by passing methods: ["read"] during creation. This ensures Claude can query credit balances and signals, but cannot execute credit-consuming enrichment operations.
• Tag Filtering: Integrations are tagged by functional area. You can pass tags: ["prospecting"] to only expose search tools, preventing the LLM from accessing billing or table management endpoints.
• Temporary Access (expires_at): If you only need an agent to run a specific enrichment campaign, you can set an ISO datetime on the expires_at property. The Truto infrastructure will automatically invalidate the URL and clean up the database records when the time expires.
• Secondary Authentication (require_api_token_auth): By default, the cryptographic token in the URL is enough to authenticate. For environments where the URL might be exposed in logs, you can enable require_api_token_auth. This forces the client to also pass a valid Truto API token in the Authorization header, requiring two distinct secrets to connect.

Moving Fast with Managed MCP

Building an LLM integration against a sprawling, credit-metered API like Lusha is an exercise in pain management. If you build it yourself, you are signing up to maintain schema definitions, handle complex asynchronous polling logic, and constantly update your tool wrappers whenever Lusha changes an endpoint.

By routing Claude through Truto's managed MCP infrastructure, you offload the entire integration lifecycle. The server is generated dynamically from living documentation, the JSON-RPC protocol is handled at the edge, and the LLM gets instant access to perfectly typed schemas - allowing your engineers to focus on building agent logic instead of API wrappers.