Personal Email to Company Resolver MCP Server

Resolve the employer behind a personal email

resolve_personal_email_employer

Read-only

Find the likely employer behind a free email address using Gravatar, signed GitHub commits, and LinkedIn resolution, returning person name, employer, domain, confidence, and evidence URLs.

Instructions

Find the likely employer behind a free mail address (Gmail, Outlook, iCloud, Yahoo, and about 140 more), from the public Gravatar profile for the address, the GitHub account whose public commits are signed with it, and Mamba Labs Person LinkedIn URL Resolver. Returns one row per address with person_name, employer_name, employer_domain when a source names it, employer_source, employer_confidence from 0 to 1, match_status (resolved at 0.75 or more, weak, name_only, corporate_email, not_found, invalid_email, blocked), the LinkedIn URL when found, and evidence_urls. It never contacts the mailbox and never opens LinkedIn. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per resolved address, and the optional LinkedIn step is billed by Person LinkedIn URL Resolver at its own price.

Input Schema

Name	Required	Description
`email`	No	One email address, for example a signup on a Gmail address.
`emails`	No	Several addresses, up to 300. A company address returns its own domain, free.
`country`	No	Two letter Google country code. Default us.
`search_web`	No	true adds one exact Google search for an address that Gravatar and GitHub leave without an employer. Default false.
`github_token`	No	Optional. Your own free GitHub token, for batches over about 25 addresses. Used for this run only and never stored.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount; it is passed to the LinkedIn step too.
`use_linkedin_resolver`	No	true (default) runs Mamba Labs Person LinkedIn URL Resolver from your account for the addresses with a name and an employer, billed at that actor's own price per person sent to it, found or not (0.035 USD on the free plan). false skips it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: per-address Apify charges, separate billing from the LinkedIn resolver at its own price, the 0.75 confidence cutoff for 'resolved', and that failures come back as errors with a run ID. It also clarifies the non-contact guarantee, which is real behavioral information an agent would not otherwise have.

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?

Front-loads the core purpose and the sources in the first sentence, then covers outputs and cost. The return-field enumeration is long but earns its place because there is no output schema; density is high but nothing is padding.

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?

Because there is no output schema, the description carries the return-value burden and does so fully: named fields, the match_status taxonomy, and confidence scale. Combined with cost, authentication (APIFY_TOKEN), and error behavior, an agent has everything needed to call it and interpret results.

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 seven parameters are already documented, and the description largely restates them. It reinforces the LinkedIn step's billing (relevant to use_linkedin_resolver and max_charge_usd) but says nothing about email vs emails batching, country, search_web, or github_token, so it adds only marginal value over the schema.

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?

States a precise verb and resource ('Find the likely employer behind a free mail address') and names the exact sources it draws on (Gravatar, signed GitHub commits, Person LinkedIn URL Resolver). No siblings exist, but the scope is unambiguous on its own.

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

Usage Guidelines4/5

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

The use case is clearly scoped to free mail addresses, and the description sets boundaries by stating it never contacts the mailbox or opens LinkedIn. It stops short of explicit when-not-to-use guidance (e.g. corporate addresses or when to prefer a different lookup), so it lands below a 5.

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

resolve_personal_email_employerA