Skip to main content
Glama

Apollo.io B2B Person Enrichment & Verified Email Finder (x402)

enrich_person

PAID ($0.03 USDC via x402 on Base — Free-on-Miss: $0.00 charged if no deliverable email is found): Verified B2B Person Enrichment, Work Email Finder & LinkedIn-to-Email Resolver powered by Apollo.io. Accepts partial identifiers—(1) first_name + last_name + company domain or organization_name, (2) LinkedIn profile URL (linkedin_url), or (3) email (reverse email lookup)—and returns a deterministic JSON profile with deliverable work email, verification status, job title, seniority (founder, C-suite, VP, director), company firmographics (headcount, industry, founded year), and full employment history. Zero signup or API key required.

Input Schema

NameRequiredDescriptionDefault
idNoOptional Apollo.io person ID for direct profile hydration.
nameNoTarget person's full name (e.g., 'Tim Zheng'). Automatically split into first_name and last_name if needed.
emailNoKnown work or personal email address for reverse-email enrichment into full LinkedIn, title, firmographics, and career history.
domainNoCompany website domain or URL (e.g., 'apollo.io', 'stripe.com'). Also accepts a company name (e.g., 'Meta', 'Google') and automatically resolves the canonical domain.
companyNoAlias for organization_name or domain (e.g., 'Meta', 'Stripe', 'instacart.com').
last_nameNoTarget person's last name (e.g., 'Zheng'). Optional if 'name', 'linkedin_url', 'email', or 'id' is provided.
first_nameNoTarget person's first name (e.g., 'Tim'). Optional if 'name', 'linkedin_url', 'email', or 'id' is provided.
linkedin_urlNoPublic LinkedIn profile URL (e.g., 'https://www.linkedin.com/in/tim-zheng') to resolve directly into a verified work email and company profile.
_x402_paymentNoOptional x402 signed payment payload (if not passed via HTTP X-PAYMENT header)
organization_nameNoCompany or organization name (e.g., 'Apollo.io', 'Meta', 'Google', 'Stripe') if exact domain is unknown.
reveal_personal_emailsNoWhether to include verified personal emails if a corporate work email is unavailable (default: false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / anyOf
      Added value: +[
      +  {
      +    "required": [
      +      "linkedin_url"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "email"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "id"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "first_name",
      +      "last_name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "first_name",
      +      "domain"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "first_name",
      +      "organization_name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "first_name",
      +      "company"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "last_name",
      +      "domain"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "last_name",
      +      "organization_name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "last_name",
      +      "company"
      +    ]
      +  }
      +]
    • changedInput schema / description
      Previous value: -"B2B Person Enrichment & Verified Work Email Finder (Apollo.io): Accepts flexible partial person identifiers—such as (1) LinkedIn profile URL only ('linkedin_url' or 'linkedin'), (2) work or personal email only ('email' for reverse email lookup), (3) name ('name' or 'first_name' + 'last_name') with company domain OR fuzzy company name ('domain', 'organization_name', or 'company', e.g. 'Meta' or 'meta.com'), or (4) Apollo person ID ('id')—and resolves a deterministic B2B executive/prospect profile with verified work email, job title, seniority, department, location, company firmographics, and employment history."New value: +"B2B Person Enrichment & Verified Work Email Finder (Apollo.io): Accepts flexible partial person identifiers—such as (1) LinkedIn profile URL only ('linkedin_url' or 'linkedin'), (2) work or personal email only ('email' for reverse email lookup), (3) name ('name' or 'first_name' + 'last_name') with company domain OR fuzzy company name ('domain', 'organization_name', or 'company', e.g. 'Meta' or 'meta.com'), or (4) Apollo person ID ('id')—and resolves a deterministic B2B executive/prospect profile with verified work email, job title, seniority, department, location, company firmographics, and employment history. Free-on-Miss: only settles payment ($0.03 USDC) when a verified person and deliverable email are returned."
  2. Changed9 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +true
    • changedInput schema / description
      Previous value: -"B2B Person Enrichment & Verified Work Email Finder (Apollo.io): Resolve partial person identifiers—such as (1) first_name + last_name + company domain/organization_name, (2) LinkedIn profile URL (linkedin_url to email), or (3) work email (reverse email lookup)—into a deterministic B2B executive/prospect profile with verified work email, job title, seniority (founder, C-suite, VP, director), department, location, company firmographics (headcount, industry, founded year), and full employment history."New value: +"B2B Person Enrichment & Verified Work Email Finder (Apollo.io): Accepts flexible partial person identifiers—such as (1) LinkedIn profile URL only ('linkedin_url' or 'linkedin'), (2) work or personal email only ('email' for reverse email lookup), (3) name ('name' or 'first_name' + 'last_name') with company domain OR fuzzy company name ('domain', 'organization_name', or 'company', e.g. 'Meta' or 'meta.com'), or (4) Apollo person ID ('id')—and resolves a deterministic B2B executive/prospect profile with verified work email, job title, seniority, department, location, company firmographics, and employment history."
    • addedInput schema / properties / company
      Added value: +{
      +  "description": "Alias for organization_name or domain (e.g., 'Meta', 'Stripe', 'instacart.com').",
      +  "type": "string"
      +}
    • changedInput schema / properties / domain / description
      Previous value: -"Company website domain without protocol (e.g., 'apollo.io', 'stripe.com'). Strongly improves match precision."New value: +"Company website domain or URL (e.g., 'apollo.io', 'stripe.com'). Also accepts a company name (e.g., 'Meta', 'Google') and automatically resolves the canonical domain."
    • changedInput schema / properties / first_name / description
      Previous value: -"Target person's first name (e.g., 'Tim'). Best combined with last_name and domain or organization_name."New value: +"Target person's first name (e.g., 'Tim'). Optional if 'name', 'linkedin_url', 'email', or 'id' is provided."
    • addedInput schema / properties / id
      Added value: +{
      +  "description": "Optional Apollo.io person ID for direct profile hydration.",
      +  "type": "string"
      +}
    • changedInput schema / properties / last_name / description
      Previous value: -"Target person's last name (e.g., 'Zheng'). Best combined with first_name and domain or organization_name."New value: +"Target person's last name (e.g., 'Zheng'). Optional if 'name', 'linkedin_url', 'email', or 'id' is provided."
    • changedInput schema / properties / name / description
      Previous value: -"Target person's full name (e.g., 'Tim Zheng') if first_name and last_name are not separated."New value: +"Target person's full name (e.g., 'Tim Zheng'). Automatically split into first_name and last_name if needed."
    • changedInput schema / properties / organization_name / description
      Previous value: -"Company or organization name (e.g., 'Apollo.io', 'Stripe') if exact domain is unknown."New value: +"Company or organization name (e.g., 'Apollo.io', 'Meta', 'Google', 'Stripe') if exact domain is unknown."
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantially well: it discloses the price ($0.03 USDC via x402 on Base), the free-on-miss billing rule, the no-signup/no-API-key auth model, and the deterministic JSON return. It omits rate limits, timeout behavior, and what happens on ambiguous multi-match, which keeps it out of the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The cost/miss rule is correctly front-loaded, which is the most important fact. The remainder is a dense marketing register ('Verified… Resolver powered by Apollo.io', em-dash lists) that partly duplicates the schema-level description, so several clauses could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, and the description compensates by enumerating the returned fields (work email, verification status, title, seniority, firmographics, employment history). It covers cost and inputs, but says nothing about failure modes for an 11-parameter tool, which is the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter and the baseline is 3. The description usefully groups the parameters into three input modes, but that grouping largely restates the anyOf structure rather than adding new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Verified B2B Person Enrichment… LinkedIn-to-Email Resolver') and enumerates the three resolution modes, so the function is unmistakable. However, it never acknowledges the sibling get_enrichment_quote, so the boundary between quoting and actually enriching is left for the agent to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied well by enumerating acceptable input shapes (LinkedIn URL, email, name+company, person ID), which tells the agent when the tool is applicable. But there is no explicit guidance on when to prefer this over get_enrichment_quote, nor any exclusion for cases where enrichment should be skipped.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.