Skip to main content
Glama
Sign In
apollo-io-mcp

apollo-io-mcp

by thevgergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Enrich Person

apollo_enrich_person

Enrich person profiles using email, LinkedIn URL, or name plus company via Apollo match. Retrieve verified contact details, including optional phone numbers and personal emails.

Instructions

Enrich a person by email, linkedin_url, or name+company using Apollo match.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "apollo_enrich_person"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
emailNo
companyNo
linkedin_urlNo
reveal_phone_numberNoReveal phone numbers (default: false)
reveal_personal_emailsNoReveal personal emails (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • changedInput schema / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. First observedv2.2.1

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden. It discloses nothing about cost/credit consumption for enrichment, whether reveal_phone_number or reveal_personal_emails incur extra charges, rate limits, or result-empty behavior. For a paid enrichment endpoint this is a substantial gap.

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

Conciseness4/5

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

One tight sentence with the resource and matching modes front-loaded. No filler, though it is arguably too terse for a six-parameter tool.

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

Completeness2/5

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

A six-parameter, zero-required-parameter mutation-adjacent tool with no output schema and no annotations needs more: which identifier combinations are valid, what happens on a miss, and whether phone/personal-email reveals are billable are all absent.

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 33%, but the description does add meaning by grouping the three matching keys (email, linkedin_url, name+company) as alternative identifiers. It omits that at least one identifier must be supplied despite zero required parameters, and says nothing about the two reveal_* flags beyond what the schema already documents.

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?

States a specific verb (enrich) and resource (a person) and names the accepted matching keys. It implicitly differentiates from siblings like apollo_bulk_enrich_people and apollo_enrich_company, though it never names them. Clear enough for an agent to identify the tool.

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

Usage Guidelines2/5

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

The description lists valid input keys but gives no when-to-use guidance: no distinction from apollo_search_people (lookup vs enrichment), no mention that this is the single-record counterpart to the bulk variant. Usage must be inferred entirely.

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

Deploy Server

Other Tools