SignupBouncer

Check a signup email (and IP)

check_email

Read-onlyIdempotent

Checks one email address, and optionally the signup's IP address, the way SignupBouncer checks a new signup. Returns the result as "verdict" (allow, challenge or block), a 0-100 score, the reasons with their reason codes, the normalized inbox (Gmail dots and +tags folded) and the IP's network. When the domain looks like a typo of a big mail provider (gmial.com), "suggestion" holds the corrected address. Looks up the domain's mail servers live. Every reason is listed, including ones only paid plans count. We don't store or log the email or IP address it checks. We cache the email's domain and its mail servers for up to an hour. For the rate limits we keep a keyed hash of the calling IP address, or of the account when the client sends a key, for up to 24 hours. When we look up a key, we also keep keyed hashes of the calling IP address and its network (/24 or /64) for up to two minutes.

Input Schema

Name	Required	Description	Default
`ip`	No	Optional IPv4 or IPv6 address the signup came from.
`email`	Yes	The email address to check.

Output Schema

Name	Required	Description
`score`	Yes
`network`	No
`reasons`	Yes
`verdict`	Yes
`normalized`	No
`suggestion`	No	The corrected address when the domain looks like a typo of a big mail provider. Absent otherwise. It does not change the score.
`data_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedOutput schema / properties / reasons / items / properties / docs_url
```
Added value: +{
+  "description": "The code's entry on the reason codes page.",
+  "type": "string"
+}
```
First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: it explains the verdict values, score range, reason codes, inbox normalization, typo suggestions, live mail-server lookup, and that all reasons are returned even if paid-plan-only. It also discloses caching and rate-limit storage practices in detail, which is valuable context for a privacy-sensitive validation tool.

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?

The description is front-loaded with the core purpose and return behavior, then moves into lookup, privacy, caching, and rate-limit details. It is information-dense and mostly earns its length, though the final sentences about hashed storage are quite detailed and could be tightened slightly.

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's complexity, privacy implications, and existing output schema, the description is highly complete. It explains what is checked, what is returned, how normalization and typo suggestions work, and what is stored or cached, leaving an agent well equipped to use the tool correctly.

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?

Schema coverage is 100%, so both parameters are already documented in the input schema. The description adds meaning by clarifying that the email is normalized with Gmail dots and +tags folded, that the optional IP is the signup IP, and that the IP's network is returned, going beyond the schema's basic field descriptions.

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?

The description clearly states that this tool checks one email address, optionally with a signup IP, and returns a SignupBouncer-style verdict. It is specific about the resource and operation, though it does not explicitly differentiate itself from sibling tools such as lookup_burner_domain or explain_reason.

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?

Usage is implied through phrases like 'the way SignupBouncer checks a new signup' and 'the signup's IP address,' which suggests this is for signup validation. However, there is no explicit when-to-use guidance, no exclusions, and no direct routing to sibling tools for related tasks.

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

All SignupBouncer 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?