Skip to main content
Glama

GoAI Moat Email Person Lookup

by com.goaimoat
OverviewDiscussionsAdmin

Server Details

Reverse email lookup: find the person behind an email (name, title, company).

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
jayniebingyu-cyber/goaimoat-mcp
GitHub Stars
0

TDQS

A3.8/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clear and singular.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (find_person_by_email), which is consistent and descriptive. No conflicting conventions exist.

Tool Count4/5

The server has a very narrow purpose—email person lookup—so a single tool is reasonable and well-scoped. It is slightly below the typical 3-15 range but appropriate for the specialized domain.

Completeness5/5

The tool fully covers the stated purpose by returning the key expected fields (name, title, company, LinkedIn). There are no obvious gaps for the given scope.

Available Tools

1 tool
find_person_by_emailFind Person By EmailBInspect

Find the person behind an email address (name, title, company, LinkedIn).

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesThe email address to look up (B2B work emails only).
license_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior2/5

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

Annotations are absent, so the description must carry the full behavioral burden. It only says what information is returned, not whether the lookup is read-only, what happens for invalid or non-B2B emails, whether external lookups have side effects, or how failures are handled.

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 one efficient sentence that front-loads the action and lists useful output fields. There is no filler, repetition, or material that duplicates the title or schema.

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

Completeness3/5

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

The output schema reduces the need to explain return values, and the tool's core purpose is simple. However, with no annotations and an undocumented license_key parameter, the description is not fully complete for confident tool invocation.

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

Parameters2/5

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

Schema coverage is only 50%: 'email' is documented but 'license_key' is not. The description adds no parameter-level meaning and does not explain whether license_key is required or how it affects the lookup, leaving a meaningful gap.

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?

Description uses a specific verb ('find'), names the resource ('email address'), and enumerates the returned attributes (name, title, company, LinkedIn). It clearly states what the tool does and needs no sibling differentiation since no siblings exist.

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?

There are no explicit when-to-use instructions or alternatives. The use case is implied by the description, and the schema adds a B2B-work-emails-only constraint, but the description itself gives no context about when this tool should be preferred or avoided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedfind_person_by_email1 field changed
      • addedInput schema / properties / license_key
        Added value: +{
+  "default": "",
+  "type": "string"
+}
  2. 1 tool update
    • First observedfind_person_by_email

Related MCP Connectors

Related MCP Servers

  • person-enrichment

    Br0ski777
    A
    license
    Not graded
    quality
    C
    maintenance
    Enriches person profiles from email addresses, returning full name, job title, company, social links, and location. Works as a drop-in replacement for Apollo person enrichment at lower cost.
    MIT

  • mcp-findymail

    pipeworx-io
    A
    license
    Not graded
    quality
    B
    maintenance
    B2B email finder and reverse-email lookup tool for finding professional email addresses via findymail.com.
    137 npm
    MIT

  • hunter-mcp

    BrennerSpear
    F
    license
    A
    quality
    D
    maintenance
    Find email addresses for people at companies and verify email validity using the Hunter.io API.
    2
    -
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