MCP server for Apollo.io contact and company enrichment
Four tools with clear action verbs and reasonable descriptions (100-200 chars each). All tools have input schemas with types and descriptions. However, output schemas are not documented in the source code, only inferred from descriptions. Parameter descriptions are present but lack detail on constraints, formats, and valid ranges. Tool descriptions include helpful cost warnings but lack explicit guidance on when to use each tool vs. alternatives. No error handling patterns visible in tool definitions.
Look up a person's email and contact details from their LinkedIn profile URL. COSTS APOLLO CREDITS — only call when you actually need the email. Do not call speculatively or in bulk without user confirmation. More accurate than find_person when you already have the LinkedIn URL, since it matches on a unique identifier rather than name + company. Returns name, email, email_status, title, company, and LinkedIn URL. Set include_phone=True to also return a phone number (costs extra Apollo credits).
Find a person's email and contact details by name and company. COSTS APOLLO CREDITS — only call when you actually need the email. Do not call speculatively or in bulk without user confirmation. Providing a job title improves match accuracy when multiple people share the same name at a company. Returns name, email, email_status (verified/likely_to_engage/unverified), title, company, and LinkedIn URL. Set include_phone=True to also return a phone number (costs extra Apollo credits).
Get firmographic details about a company. Accepts either a company name (e.g. "Acme Pharma") or domain (e.g. "acme.com") — domain matching is more precise when available. Returns name, domain, website, industry, employee count, and a short description. Useful for qualifying leads before outreach.
Find people who work at a given company. COSTS APOLLO CREDITS per result — keep max_results low (5 or less) unless the user explicitly asks for more. Do not call in bulk without user confirmation. Accepts either a company name (e.g. "Acme Pharma") or domain (e.g. "acme.com") — domain matching is more precise when available. Optionally filter by job title (e.g. "Head of Chemistry", "CEO"). Returns up to max_results contacts with name, email, email_status, title, and LinkedIn URL.
Output schemas not documented. Tool descriptions mention return fields (name, email, title, etc.) but no formal schema is visible in source code. LLMs cannot plan downstream tool calls or extract structured data without knowing the response shape.
Parameter constraints missing. 'max_results' has a default of 10 but no min/max bounds documented. 'company' and 'linkedin_url' lack format guidance (e.g., 'domain matching is more precise' but no regex or example format). LLMs cannot validate inputs without explicit constraints.
No error handling guidance. Descriptions warn about cost but do not explain what happens on API errors, rate limits, or invalid inputs. LLMs have no recovery path if a call fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Tool selection ambiguity. 'find_person' and 'enrich_by_linkedin' both return email and contact details. Descriptions do not clearly state when to use one vs. the other (e.g., 'use enrich_by_linkedin when you have a LinkedIn URL; use find_person when you only have name + company'). LLMs may waste reasoning cycles or pick the wrong tool.
Parameter descriptions lack actionable detail. 'company' parameter in find_person says 'Company name' but does not clarify whether it accepts domain, ticker, or only display name. 'title' parameter lacks guidance on format (e.g., 'exact match or substring?').