An AI agent qualifies a lead automatically by pulling real-time company signals for that lead’s domain at the moment of scoring, instead of reading CRM fields that were enriched weeks ago. Most AI SDR builds still do the second thing, which is why they score with confidence against hiring, funding, and technology evidence that has already changed. The fix is a narrow, repeatable call pattern: anchor the lead on a domain, pull three to five live signal sets through the Model Context Protocol (MCP), then score what comes back against a rubric the agent cannot improvise around. This guide walks through that loop using a real company record pulled on September 11, 2026, the exact fields to score on, and the credit math that keeps it affordable at volume.
TLDR:
- Lead qualification is not lead discovery. Discovery starts with a signal and returns companies; qualification starts with one company and returns signals.
- The minimum viable call pattern is three company-scoped MCP calls per lead: company, technology_detections, and job_openings. Add financing_events and news_events only when the score is borderline.
- Score on timestamps, not presence. A first_seen_at inside the last 30 days is a different signal from a detection that has been stable for three years.
- Technology Detections are evidence of use, not proof of an install, so a rubric should weight a detection plus a matching open role higher than either signal on its own.
- PredictLeads exposes 130.7M+ company records, 1.5B+ Technology Detections since 2018, and 279.2M+ Job Openings records since 2018 through one MCP server at mcp.predictleads.com.
What Real-Time Lead Qualification Means for an AI Agent
Real-time lead qualification is the act of scoring one known lead against company signals fetched at the moment of scoring, not against fields stored during an earlier enrichment run. The agent already has the lead. A form was filled, a CRM object was created, a webhook fired, or a list was uploaded. Its only job is to answer two questions: does this account deserve a rep’s time this week, and what is the evidence.
Three conditions have to hold for that answer to be trustworthy. Signals must be fetched on demand, because a flat file written last night cannot contain a detection found this morning. Every signal must carry a timestamp, because recency is most of the score. And the rubric must be explicit, because an agent asked to “judge fit” produces a different answer on every run.
That is the practical gap between static enrichment and live enrichment through MCP, and it is the reason MCP has become the default interface for agent-driven company enrichment: one standard transport, one set of credentials, and current data at the moment the agent needs it.
Every PredictLeads dataset is point-in-time and carries first_seen_at and last_seen_at, which is what turns recency from a guess into a field the agent can read.
Qualification Is Not Discovery, and That Changes the Call Pattern
Discovery and qualification use different endpoints, different inputs, and different credit math, so an agent that treats them as one workflow will spend credits badly and return the wrong shape of answer. Discovery is a search. Qualification is a lookup.
| Dimension | Discovery pass | Qualification pass |
|---|---|---|
| Input | A signal: a technology name, an O*NET code, a financing type, a location | One domain the agent already holds |
| Endpoint family | discover_* endpoints | Company-scoped endpoints under /companies/{domain}/ |
| What comes back | A list of companies matching the signal | Every signal on file for one company, with timestamps and sources |
| Credit behavior | Typically 1 credit per record returned | Typically 1 credit per response |
| Where it sits | Top of funnel: build the list | Mid funnel: rank and route what is already in the list |
If your agent still has to build the list first, that is the job of a company discovery engine on the PredictLeads MCP server, which chains the discover_* endpoints into a single pass. This guide picks up one step later, when the lead already exists and the agent has to decide what to do with it today.
What the Agent Actually Sees on One Company
Here is a real qualification pass, run through the PredictLeads MCP server on September 11, 2026, against Ramona Optics, Inc. (ramonaoptics.com), a computational microscopy company in Durham, North Carolina. Three company-scoped calls, one domain, no hypotheticals.
The interesting field is the Salesforce detection with a first_seen_at of September 11, 2026, the same day the agent ran. Its source is one of the company’s own open sales job postings, classified under O*NET code 41-4011.00, Sales Representatives, Wholesale and Manufacturing, Technical and Scientific Products. Read that carefully: it is evidence that Ramona Optics uses or intends to use Salesforce, surfaced through a hiring requirement. It is not proof of a live production instance, and a careful rubric should not treat it as one.
The rest of the record gives the agent context. A Rippling detection first seen on July 21, 2026 points to HR and payroll infrastructure being put in place earlier in the year. A separate cluster of detections tied to earlier 2026 job postings covers PyTorch, TensorFlow, NumPy, and SciPy, which describes a machine-learning-heavy product team rather than a commercial one.
Stack those three facts and the pattern is legible: an engineering-led company that put HR systems in place in July and is now standing up a technical sales function, with CRM evidence appearing the same day the agent looked. For anyone selling into revenue teams, that is a materially different lead than the same domain looked like on September 10. No batch enrichment file written yesterday contains it. This is the same logic behind pairing hiring and technographic signals for technology lead generation, compressed into a single agent call.
PredictLeads has recorded 1.5B+ Technology Detections since 2018 across 95M+ domains, and each one carries first_seen_at, last_seen_at, source_count, and a behind_firewall boolean, so the agent can weigh how a signal was found, not only that it exists.
How to Build the Qualification Loop in Four Steps
Step 1: Anchor the lead on a domain
Resolve every inbound lead to a single company domain before you call anything. Domain is the primary identifier across PredictLeads datasets, so a lead that arrives as a free-text company name has to be normalized first. Handle redirects explicitly: the Companies dataset exposes a redirects_to field with a reason of acquisition_merger, locality, or rebranding, which tells the agent when the domain in the CRM is no longer the operating entity. Skipping this step is the most common reason agents return empty signal sets and mark good accounts as cold.
Step 2: Pull the signal set in one pass
Run three calls by default, mapping to /companies/{domain}, /companies/{domain}/technology_detections, and /companies/{domain}/job_openings. Those three answer who the company is, what technology evidence exists, and what it is hiring for. Add /companies/{domain}/financing_events and /companies/{domain}/news_events as a conditional second pass, triggered only when the first three produce a score near your routing threshold. Filter server side rather than in the model: job_openings supports active_only and first_seen_at_from, and news_events supports found_at_from and categories, so the agent should never be reasoning over a year of history to answer a question about the last 30 days. If you want the full tool-calling scaffold, the walkthrough on building an enrichment agent on the PredictLeads MCP server covers the connection and prompt structure.
Step 3: Score on freshness and source, not presence
Presence scoring is what makes AI qualification feel arbitrary. Every mid-size company has a detection for something. What separates a lead worth a call today from one worth a nurture sequence is when the signal appeared and where it came from. Give the agent a fixed rubric with named fields so the same input always produces the same score.
| Signal | Field the agent reads | What it is evidence of | Weight |
|---|---|---|---|
| Technology detection plus a matching open role | seen_on_job_openings, onet_data.code | Stronger supporting evidence of an active initiative | Highest |
| New technology detection in the last 30 days | first_seen_at, source_count, behind_firewall | Recent adoption, a hiring requirement, or client work | High |
| Financing event in the last 90 days | effective_date, amount_normalized, financing_type_normalized | New budget entering the business | High |
| Hiring concentration in the buying department | categories, seniority, first_seen_at | A team being built rather than backfilled | Medium-high |
| Expansion news event | category (expands_facilities), found_at, confidence | Physical or headcount growth | Medium |
| A technology no longer detected | last_seen_at | Ambiguous: script change, recrawl gap, or signature change | Low, never a disqualifier alone |
That last row matters more than it looks. Agents are eager to conclude that a company dropped a vendor because a detection stopped appearing. A gap in detection means the signal has not been seen since a given date, and nothing more. Write the rule into the system prompt so the model cannot narrate its way past it.
Step 4: Route the lead and write the evidence back
A score with no evidence is unusable by the rep who receives it. Have the agent write back three things: the numeric score, the two or three signals that drove it, and the timestamp and source URL of each. PredictLeads links every technology detection to its original source, whether that is a subpage URL, a job opening URL, or a DNS record, so the note a rep opens can say exactly which job posting produced the detection. Teams that prefer not to build the loop in code can assemble the same pattern with no-code AI agents connected to PredictLeads through n8n, Make, or Zapier.
How you fetch depends on volume, and this is where most builds get the economics wrong.
| Monthly leads to qualify | Delivery method | Why |
|---|---|---|
| Under 5,000 | MCP or REST API, on demand | Simplest to build, and every lead gets data fetched at the moment of scoring |
| 5,000 to 50,000 | Follow companies plus webhooks, with MCP for ad hoc lookups | Signals are pushed as they are detected, so the agent reacts instead of polling |
| Above 50,000 | Flat files into the warehouse, plus MCP on borderline leads | Bulk scoring runs on the warehouse; live calls are reserved for the leads where recency decides the outcome |
Job Openings alone covers 279.2M+ historical records since 2018 across 2.9M+ websites, with 10.2M active openings at any time, which is enough depth for the agent to compare a current hiring pattern against the same company’s own history rather than an industry average.
Funding and Expansion Signals in the Same Pass
Technology and hiring are the workhorse signals, but the conditional second pass is where borderline leads get resolved. On September 10, 2026, PredictLeads recorded Series A rounds with that effective_date for two companies: Aqua at $15M and Luminary at $22M. On the same day it recorded an expansion news event for AEVEX Corp. (NYSE: AVEX), covering facility expansion in Florida and Virginia.
The point is not the individual companies. It is that an agent qualifying a lead on September 11 can read events dated September 10 as structured fields: financing_type_normalized set to series_a, amount_normalized as a USD integer, and a news category of expands_facilities with its own found_at. That is a categorized event, not an article the model has to interpret. Across the dataset there are 210,800+ Financing Events since 2016 and 10M+ News Events since 2016 spread over 37 categories, so the second pass has something to find in most industries.
MCP Is How the Agent Asks, Not What It Detects
One distinction gets blurred constantly, and blurring it produces a factual error in your scoring logic. Model Context Protocol is the transport your agent uses to reach a data source. It is not a technology PredictLeads tracks as a technographic signal about your target accounts. A search of the Technologies catalog on September 11, 2026 returns no Model Context Protocol entry.
So you cannot qualify a lead on “this company has adopted MCP.” You can qualify a lead on the 50,000+ technologies that are in the catalog, detected across five source types: website script tags, DNS records, IP ranges, cookies, and job descriptions. That fifth source is why enterprise tools sitting behind a login still show up, flagged with the behind_firewall boolean, which is exactly how the Salesforce evidence in the Ramona Optics example surfaced at all. If you are still choosing an interface, the comparison of MCP servers for company enrichment covers the trade-offs.
Credits, Rate Limits, and Freshness
Real-time qualification is cheap per lead and expensive if you design it carelessly, so put the operating limits into the agent’s retry logic before you ship it.
| Constraint | Value | What the agent should do |
|---|---|---|
| Rate limit | 60 requests per second | Space requests rather than burst; back off on 429 using the Retry-After header |
| Credit ceiling | 402 returned when the monthly limit is exceeded | Poll GET /api_subscription, which costs 0 credits, and degrade to cached scores |
| Cost per qualified lead | About 3 credits for the default pass, 5 with the conditional pass | Gate the extra two calls behind a score threshold instead of running them on every lead |
| Job data freshness | Job openings refreshed approximately every 36 hours | Do not re-poll the same domain hourly; reserve re-scoring for webhook triggers |
| Crawl cadence | High-traffic websites crawled multiple times daily | Treat same-day first_seen_at values as expected, not anomalous |
Responses follow the JSON:API specification, list endpoints are paginated with a page parameter, and most support up to 1,000 results per page. The full schema is published as an OpenAPI schema, which is the file to hand your agent framework if you want typed tool definitions rather than hand-written ones. Setup for the MCP transport itself is documented at docs.predictleads.com/mcp_integration.
How PredictLeads Supports Real-Time Lead Qualification
PredictLeads is the data layer an AI agent queries during qualification, not the agent and not the CRM. That distinction is the reason it fits behind whatever you are building: the same records reach a Python agent, a warehouse job, and a no-code workflow without a separate contract per surface.
Three properties matter specifically for qualification. Source transparency means every technology detection links back to the subpage, job opening, or DNS record that produced it, so the agent can attach proof to a score. Multi-source detection across script tags, DNS records, IP ranges, cookies, and job descriptions raises the hit rate on enterprise tools that never appear in front-end code. And point-in-time timestamps on every dataset let the agent compare a company against its own history instead of a static benchmark.
Adjacent datasets extend the same pass when your scoring model needs them: Connections carries 371.8M+ company relationships since 2019 for warm-path and ecosystem checks, Similar Companies covers 18.9M+ companies with up to 50 lookalikes and a text reason for the top 20, and Website Evolution tracks 776M+ subpages since 2021 for build-out signals like a new pricing or integrations page. The comparison of company intelligence APIs for AI workflows lays out how these fit together for builders.
Delivery is the same data through four surfaces: API, flat files, webhooks, and MCP at mcp.predictleads.com. PredictLeads is SOC 2 Type II certified, GDPR and CCPA compliant, and collects only publicly available company-level information, with no personally identifiable information in the company intelligence datasets, which is the answer your security review will ask for before an agent goes to production.
Final Thoughts on AI Agent Lead Qualification
The hard part of automated lead qualification is not the model. It is giving the agent signals that were true at the moment it looked, and a rubric that stops it from over-reading them. Three calls per lead, timestamps weighted above presence, a detection plus a matching open role weighted above either one alone, and a detection gap treated as ambiguous rather than as churn. That is the whole discipline. Once it is running, the natural next step is to widen the funnel that feeds it, which is where live company signals across the full lead generation motion take over.
Ready to see this in your own data?
Get 100 free API requests when you create an account – no credit card, no sales call.
Frequently Asked Questions
How does an AI agent qualify a lead in real time?
The agent resolves the lead to a company domain, then calls a live data source for that domain at the moment of scoring rather than reading stored CRM fields. A practical default is three company-scoped calls: company, technology_detections, and job_openings, with financing_events and news_events added only when the score lands near the routing threshold. Each returned signal carries first_seen_at and last_seen_at, so the agent can weight recency instead of treating all evidence as equally current. Through the PredictLeads MCP server at mcp.predictleads.com, that pass typically costs about 3 credits per lead.
What is the difference between lead discovery and lead qualification for an AI agent?
Discovery starts with a signal and returns a list of companies; qualification starts with one company and returns its signals. Discovery uses the discover_* endpoints and is typically billed at 1 credit per record returned, while qualification uses company-scoped endpoints under /companies/{domain}/ and is typically billed at 1 credit per response. An agent that runs discovery logic on a lead it already has will spend credits building a list it does not need. Both patterns run over the same PredictLeads data covering 130.7M+ companies across 195 countries.
Which company signals should an AI agent use to score a lead in 2026?
Weight a technology detection paired with a matching open role highest, because two independent sources pointing at the same initiative is stronger supporting evidence than either alone. Then new detections inside the last 30 days, financing events inside the last 90 days, hiring concentration in the department that would buy from you, and expansion news. Read the fields directly: first_seen_at, behind_firewall, source_count, onet_data.code, seniority, financing_type_normalized, and amount_normalized. PredictLeads categorizes every job opening with an O*NET code, which lets the agent compare hiring patterns consistently across companies and industries.
Can an AI agent tell whether a company actually uses a technology?
No, and a scoring rubric should say so explicitly. Technology Detections provide evidence of which technologies a company uses or has recently used, gathered from script tags, DNS records, IP ranges, cookies, and job descriptions. A detection sourced from a job description may indicate current usage, planned adoption, a migration, client work, or simply a hiring requirement, so the agent should describe the evidence and its source rather than assert an install. The behind_firewall boolean and source_count fields tell the agent how the evidence was found and how many independent sources support it.
How many API credits does real-time lead qualification cost per lead?
Company-specific endpoints are typically billed at 1 credit per response, so the three-call default pass costs about 3 credits per lead and the conditional five-call pass costs about 5. Gate the extra two calls behind a score threshold so they only run on borderline leads. Checking GET /api_subscription costs 0 credits, which makes it safe to poll for remaining monthly credits before a large batch. Every new PredictLeads account includes 100 free API requests, which is enough to qualify roughly 30 leads end to end with the default pass.