AIsa Go-To-Market

People Enrichment

post_apollo_people_match

Read-onlyIdempotent

Enrich one person: give whatever identifiers you have and get back Apollo's full record for them. Accepts email, first_name plus last_name, name, domain, organization_name, linkedin_url or hashed_email — the more you supply, the likelier the match. Returns a person object with id, name, title, headline, linkedin_url, twitter_url, github_url, photo_url, organization_id and an employment_history array, plus a request_id. Personal emails and phone numbers are withheld unless reveal_personal_emails or reveal_phone_number is set, and those cost extra credits. A 200 does not guarantee a match — check whether person actually came back. Use post_apollo_people_bulk_match for up to 10 people in one call; use post_apollo_mixed_people_api_search when you do not have an identifier and need to find candidates first.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	The Apollo ID for the person. Each person in the Apollo database is assigned a unique ID. To find IDs, call the People API Search endpoint and identify the values for person_id. Example: 587cf802f65125cad923a266
`name`	No	The full name of the person. This will typically be a first name and last name separated by a space. If you use this parameter, you do not need to use the first_name and last_name parameters. Example: tim zheng
`email`	No	The email address of the person. Example: example@email.com
`domain`	No	The domain name for the person's employer. This can be the current employer or a previous employer. Do not include www., the @ symbol, or similar. Example: apollo.io or microsoft.com
`last_name`	No	The last name of the person. This is typically used in combination with the first_name parameter. Example: zheng
`first_name`	No	The first name of the person. This is typically used in combination with the last_name parameter. Example: tim
`webhook_url`	No	If you set the reveal_phone_number parameter to true, this parameter becomes mandatory. Otherwise, do not use this parameter. Enter the webhook URL that specifies where Apollo should send a JSON response that includes the phone number you requested. Apollo suggests testing this flow to ensure you receive the separate response with the phone number. If phone numbers are not revealed delivered to the webhook URL, try applying UTF-8 encoding to the webhook URL. Example: https://webhook.site/cc4cf44e-e047-4774-8dac-473d28474e40; https%3A%2F%2Fwebhook.site%2Fcc4cf44e-e047-4774-8dac-473d28474e40
`hashed_email`	No	The hashed email of the person. The email should adhere to either the MD5 or SHA-256 hash format. Example: 8d935115b9ff4489f2d1f9249503cadf (MD5) or 97817c0c49994eb500ad0a5e7e2d8aed51977b26424d508f66e4e8887746a152 (SHA-256)
`linkedin_url`	No	The URL for the person's LinkedIn profile. Example: http://www.linkedin.com/in/tim-zheng-677ba010
`organization_name`	No	The name of the person's employer. This can be the current employer or a previous employer. Example: apollo
`reveal_phone_number`	No	Set to true if you want to enrich the person's data with all available phone numbers, including mobile phone numbers. This potentially consumes credits as part of your Apollo pricing plan . The default value is false. If this parameter is set to true, you must enter a webhook URL for the webhook_url parameter. Apollo will asynchronously verify phone numbers for you, then send a JSON response that includes only details about the person's phone numbers to the webhook URL you provide. It can take several minutes for the phone numbers to be delivered.
`run_waterfall_email`	No	Set to true to enable email waterfall enrichment
`run_waterfall_phone`	No	Set to true to enable phone waterfall enrichment
`reveal_personal_emails`	No	Set to true if you want to enrich the person's data with personal emails. This potentially consumes credits as part of your Apollo pricing plan . The default value is false. If a person resides in a GDPR -compliant region, Apollo will not reveal their personal email.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: personal emails and phone numbers are withheld unless reveal flags are set, those reveals cost extra credits, phone numbers are delivered asynchronously to a webhook, and HTTP 200 can still mean no match. These details meaningfully inform an agent's expectations without contradicting the readOnly, idempotent, and non-destructive annotations.

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

Conciseness5/5

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

The description is long but every sentence earns its place: the identifier list, the match-likelihood heuristic, the returned object shape, the hiding/credit behavior, the response caveat, and the sibling routing. It is front-loaded with the core action and uses the sibling distinction where it matters.

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

Completeness5/5

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

Given the tool has 14 parameters, zero required parameters, and a rich input schema, the description covers all non-obvious behavior an agent needs to call it correctly: match probability, hidden data, costs, webhook delivery, match-failure semantics, and alternatives. The output schema exists, so return values do not need duplication in prose.

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

Parameters4/5

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

Since schema description coverage is 100%, the individual parameter documentation already carries the load. The description still adds value by grouping identifiers as a set, stating that supplying more identifiers increases match likelihood, and by explaining the credit/cost implication of reveal_personal_emails and reveal_phone_number.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Enrich one person' against Apollo's people records, and clearly states the input-to-output contract (identifiers in, full record back). It also explicitly names sibling tools, such as post_apollo_people_bulk_match and post_apollo_mixed_people_api_search, so an agent can distinguish this tool without opening schemas.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: use this for single-person enrichment when you have at least one identifier, use post_apollo_people_bulk_match for up to 10 people, and use post_apollo_mixed_people_api_search when no identifier exists and candidates must be found first. It also warns that a 200 response does not guarantee a match, telling the agent to check the returned person object.

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

All AIsa Go-To-Market tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?