Connect MoltSets to AI Agents: Automate Prospecting & Sourcing

You want to connect MoltSets to an AI agent so your system can autonomously prospect target accounts, look up business profiles, and verify contact information based on dynamic intent signals. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to build a custom data sourcing integration from scratch.

Giving a Large Language Model (LLM) read access to a complex B2B data provider like MoltSets requires strict guardrails. AI agents left to guess API payloads will quickly hallucinate parameters, waste API tokens on invalid queries, or trigger rate limit blocks. If your team uses ChatGPT, check out our guide on connecting MoltSets to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting MoltSets to Claude. For developers building custom autonomous workflows, you need a programmatic way to fetch these tools and bind them to your agent framework.

This guide breaks down exactly how to fetch AI-ready tools for MoltSets, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex lead generation workflows. For a broader look at this design pattern, read our guide on Architecting AI Agents: LangGraph, LangChain, and the SaaS Integration Bottleneck.

Why a Unified Tool Layer Matters for Agent Safety

Before writing a line of integration code, you must decide what layer your agent will talk to. This choice determines the safety, cost efficiency, and reliability of your production system.

Direct API tools - writing one bespoke function per raw MoltSets endpoint - look convenient in a prototype. However, they push provider specific quirks directly into the LLM's context window. The model has to memorize that certain searches require positive filters, that specific ad audience endpoints are gated behind expensive subscription tiers, and that pagination limits must be respected. Every one of those quirks is a hallucination waiting to happen.

A unified tool layer collapses these endpoints behind a strict JSON schema that Truto manages. Your agent sees stable, declarative functions like molt_sets_business_emails_search and list_all_molt_sets_search_companies. This provides concrete safety wins:

1. Deterministic input validation. Every tool has a strict JSON schema. Invalid arguments are rejected before they ever hit the MoltSets API, saving you from burning credits on malformed HTTP requests.
2. Reduced hallucination surface. The LLM only chooses from defined function names. It never invents query strings or guesses pagination cursors.
3. Real-time schema updates. When MoltSets changes its API, Truto updates the integration definition centrally. Your agent inherits the correct schema on its next initialization without you redeploying code.

The Engineering Reality of the MoltSets API

Giving an LLM access to external data sounds simple until you hit production. Standard LLMs are trained to expect flat, intuitive REST interactions. The MoltSets API introduces several specific integration challenges that will break standard assumptions. If you hardcode these interactions into your agent, you will spend your sprints writing defensive integration code instead of improving your model's reasoning.

The Token Economics of Queries

MoltSets operates on a token-based economy that requires careful programmatic handling. Unlike standard SaaS APIs where you simply pay for a monthly volume of requests, MoltSets charges tokens based on the outcome of the request.

If your agent searches for an email and the API returns a not_found miss, the query is free. If data is found, it costs 1 token. When your agent is running autonomous loops, it can rapidly drain your token balance if it is caught in a loop of positive but irrelevant hits. You must ensure your agent logic is tightly constrained to only query for high-intent targets, rather than doing broad exploratory loops.

Plan-Restricted Endpoints and 403 Errors

The MoltSets API aggressively gates specific data points behind subscription plans. For example, looking up a mobile advertising ID (AAID or IDFA) via molt_sets_ad_audiences_lookup_maid_by_email or searching for personal USA emails will return a strict 403 plan_restricted error if you are on a $397 or $997 tier that does not include these features.

Your agent framework needs to understand how to interpret a 403 error. If you do not handle this, an agent might assume it made a bad request and retry it endlessly, or hallucinate a fake response to satisfy its internal goal. By providing the agent with exact schema definitions and explicit error descriptions via Truto, the LLM learns that a 403 means "stop trying this tool for this account" rather than "try again with different parameters."

Mandatory Positive Filters

When using the search endpoints like list_all_molt_sets_search_people or list_all_molt_sets_search_companies, MoltSets strictly requires at least one positive filter. You cannot send an empty query object to dump the database.

Standard LLMs often try to fetch all records and filter them in memory. If an agent submits an empty query, MoltSets will reject it. Truto's tool schema enforces this requirement, ensuring the LLM formulates a precise query (e.g., searching by domain or industry) before the network request is initiated.

Handling Rate Limits the Right Way

Rate limiting is the most common failure point for autonomous agents making external API calls. Truto does not retry, throttle, or apply backoff on rate limit errors. This is an intentional architectural decision to prevent hidden latency spikes in agent execution loops.

When the MoltSets API returns an HTTP 429 (Too Many Requests), Truto passes that exact error back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers per the IETF specification:

• ratelimit-limit: The maximum number of requests allowed in the current window.
• ratelimit-remaining: The number of requests left in the current window.
• ratelimit-reset: The time at which the rate limit window resets.

The caller - your agent framework - is entirely responsible for reading these headers, pausing execution, and applying exponential backoff.

Fetching MoltSets Tools via Truto

Truto maps every endpoint on the MoltSets integration into a Resource and Method. These methods are then exposed as Proxy APIs. By calling Truto's /tools endpoint, you retrieve a list of all available Proxy APIs formatted specifically for LLM consumption.

This is not limited to LangChain. Because the /tools endpoint returns standard JSON, you can map these tools into the Vercel AI SDK, CrewAI, AutoGen, or raw OpenAI function calls.

Here is how you initialize the tools using the truto-langchainjs-toolset:

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
 
// Initialize the LLM
const llm = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
});
 
// Initialize the Truto Tool Manager
// You need your Truto PAT and the Integrated Account ID for MoltSets
const toolManager = new TrutoToolManager({
  trutoAccessToken: process.env.TRUTO_TOKEN,
  integratedAccountId: process.env.MOLTSETS_ACCOUNT_ID,
});
 
async function runAgent() {
  // Fetch the MoltSets tools dynamically from Truto
  const tools = await toolManager.getTools();
  
  // Bind the tools to the LLM
  const llmWithTools = llm.bindTools(tools);
  
  // The LLM is now aware of MoltSets capabilities and can trigger them
  const response = await llmWithTools.invoke(
    "Find the company profile for Acme Corp using their domain acme.com"
  );
  
  console.log(response.tool_calls);
}
 
runAgent();

When the agent decides to invoke a tool, the framework passes the LLM's JSON arguments back to Truto. Truto handles the authentication against MoltSets, executes the request, normalizes the response, and hands it back to the agent.

Hero Tools for MoltSets

Providing an agent with too many tools degrades its decision-making accuracy. You should filter the tools you bind to the agent based on the specific workflow you want it to execute. Here are the highest-leverage hero tools available for MoltSets.

Search Companies Database

Tool name: list_all_molt_sets_search_companies

This tool allows the agent to search the MoltSets company database by firmographic data such as name, domain, industry, headcount, revenue, NAICS code, or location. It returns ranked company profiles. It requires at least one positive filter and returns a maximum of 25 records per page.

"Find software companies in Austin, Texas with a headcount between 50 and 200 employees, and list their domains."

Search People Database

Tool name: list_all_molt_sets_search_people

Agents use this tool to discover prospects based on specific professional criteria. You can search by name, title, employer, seniority, department, industry, company size, or location. It returns ranked profiles including the associated company and business email.

"Find the VP of Engineering at companies in the cybersecurity industry based in London."

Find LinkedIn Profiles by Name and Domain

Tool name: molt_sets_linkedin_profiles_search

This is a critical bridging tool. When an agent has a person's name and their company domain, this tool finds the matching LinkedIn profile URL. You can also instruct the agent to set count_only to true if it just needs to verify existence without spending a token.

"Find the LinkedIn profile URL for John Doe who works at acme.com. Run a count-only check first to see if a match exists before pulling the full profile."

Lookup Business Profile by LinkedIn URL

Tool name: molt_sets_business_profiles_lookup_by_linkedin

Once an agent has a LinkedIn URL, it can use this tool to retrieve the most complete business profile available. This includes name, title, location, employer firmographics, and both business and personal emails complete with risk scores.

"Retrieve the full business profile, including firmographics and email risk scores, for the LinkedIn profile https://www.linkedin.com/in/johndoe/."

Lookup Business Email by LinkedIn URL

Tool name: molt_sets_emails_lookup_business_by_linkedin

If you only need a verified work email and want to avoid pulling massive profile payloads, use this targeted tool. It accepts a single linkedin_url or an array of up to 100 profiles (linkedin_urls) for batch processing.

"Extract the verified business emails for these three LinkedIn URLs: [URL1], [URL2], [URL3]."

Lookup Mobile Phones by LinkedIn URL

Tool name: molt_sets_mobile_phones_lookup_by_linkedin

Agents use this tool to extract carrier-verified mobile numbers associated with a LinkedIn profile. Note that this spends a separate paid phone-token, so agents should be prompted to use this sparingly and only for high-value prospects.

"Find the carrier-verified mobile phone number for the Director of Sales whose LinkedIn profile is https://www.linkedin.com/in/janedoe/."

For the complete inventory of available API tools and their exact JSON schemas, visit the Truto MoltSets integration page.

Workflows in Action

When you bind these tools to an agent, you stop writing linear, brittle scripts. The agent uses reasoning to chain these tools together, adapting to misses and errors dynamically. Here are concrete examples of workflows you can build.

Workflow 1: Account-Based Marketing (ABM) Sourcing

The Prompt:

"We are targeting mid-market SaaS companies. Find 5 software companies in Seattle with revenue between $10M and $50M. Then, find the Chief Marketing Officer at each of those companies and retrieve their verified business email and LinkedIn URL."

The Agent Execution:

1. The agent calls list_all_molt_sets_search_companies with filters for industry=software, location=Seattle, and the specified revenue range.
2. MoltSets returns a list of matching company profiles, including their exact domains.
3. The agent loops through the results and calls list_all_molt_sets_search_people for each domain, filtering for title=Chief Marketing Officer.
4. The agent compiles the resulting names, business emails, and LinkedIn URLs into a clean output array for the user.

The Result: The user receives a highly targeted, verified list of decision-makers matching precise firmographic criteria, gathered autonomously without manual list building.

Workflow 2: Inbound Lead Enrichment and Phone Sourcing

The Prompt:

"A new lead just signed up with the email alice.smith@techcorp.com. Find her full business profile, map her to her LinkedIn URL, and if she is a Director or above, find her mobile phone number."

The Agent Execution:

1. The agent calls molt_sets_business_profiles_lookup_by_email using the provided email address.
2. The API returns the profile, which includes her title (e.g., "Director of Operations") and her LinkedIn URL.
3. The agent evaluates the title against the condition ("Director or above"). Since the condition is met, it proceeds.
4. The agent calls molt_sets_mobile_phones_lookup_by_linkedin using the URL retrieved in step 2 to fetch the carrier-verified mobile number.

The Result: The system enriches a raw email address into a complete profile and selectively spends a phone-token only when the prospect meets the required seniority threshold.

Workflow 3: Ad Audience Hashing for Retargeting

The Prompt:

"Take this list of 10 target account LinkedIn URLs and generate the SHA256 and MD5 hashes of their associated business and personal emails so we can push them to our ad platform for customer match."

The Agent Execution:

1. The agent parses the list of URLs.
2. It calls molt_sets_ad_audiences_lookup_hashes_by_linkedin, passing the array of URLs.
3. If the account is on a restricted plan, the tool returns a 403 plan_restricted error. The agent catches this and informs the user that the operation cannot be completed due to account tier limits.
4. If successful, it receives the hashes (excluding records with no data) and prepares the payload.

The Result: The user receives a privacy-compliant list of email hashes ready for ad platform ingestion, with the agent intelligently handling bulk array inputs and potential plan-restriction errors.

flowchart TD
    A["Agent receives<br>LinkedIn URLs"] --> B["Agent formats<br>Array Payload"]
    B --> C["Call molt_sets_ad_audiences...<br>via Truto"]
    C --> D{"HTTP Status"}
    D -->|"200 OK"| E["Extract SHA256/MD5<br>Hashes"]
    D -->|"403 Forbidden"| F["Alert User:<br>plan_restricted"]
    E --> G["Format for<br>Ad Platform"]

Building Multi-Step Workflows

To run these workflows reliably, you need an agent loop that can handle tool execution, process the results, and deal with inevitable network realities like rate limits.

Frameworks like LangGraph allow you to define state machines that handle these iterations perfectly. When the LLM decides to call a tool, it outputs a tool_call object. Your code executes the function and returns a tool_message to the LLM. If the execution fails (for example, due to an HTTP 429), your code must catch it, apply backoff, and retry, or inform the LLM so it can alter its plan.

Here is a conceptual example of how to structure the execution loop to handle rate limits explicitly, since Truto passes the 429 response directly to you:

import { ToolNode } from "@langchain/langgraph";
 
// Assuming 'tools' is the array fetched from TrutoToolManager
const toolNode = new ToolNode(tools);
 
async function executeToolWithBackoff(toolCall, maxRetries = 3) {
  let attempt = 0;
  
  while (attempt < maxRetries) {
    try {
      // Execute the tool call against Truto
      const result = await toolNode.invoke(toolCall);
      return result;
    } catch (error) {
      if (error.response && error.response.status === 429) {
        // Read the standardized IETF headers provided by Truto
        const resetTime = error.response.headers['ratelimit-reset'];
        const retryAfter = resetTime ? 
            Math.max(0, parseInt(resetTime) * 1000 - Date.now()) : 
            Math.pow(2, attempt) * 1000;
            
        console.warn(`Rate limit hit. Retrying in ${retryAfter}ms`);
        await new Promise(resolve => setTimeout(resolve, retryAfter));
        attempt++;
      } else if (error.response && error.response.status === 403) {
         // Handle plan restrictions immediately without retrying
         return { 
           error: "Access denied. This endpoint is restricted on your current MoltSets plan."
         };
      } else {
        throw error;
      }
    }
  }
  throw new Error("Max retries exceeded for tool call");
}

This pattern ensures that your agent does not crash when MoltSets limits traffic, and it prevents the agent from infinitely hallucinating retries when hitting a hard 403 plan restriction. The agent maintains its context and can reason about the next best step.

Wrapping Up

Building AI agents that autonomously prospect and enrich B2B data requires rock-solid integration foundations. If your agent is busy trying to parse nested JSON or guess correct filter parameters, it isn't doing its job. By utilizing Truto's /tools endpoint, you abstract away the API boilerplate, enforce strict schema validation, and give your LLM a safe, declarative interface to the MoltSets database. You retain complete control over rate limiting and error handling in your application layer, ensuring your system scales reliably in production.