Proxy Mail QA

Create a test email address

create_address

Creates a disposable email address in the project "Welcome To Test" for signing up to the app under test. It's on @mailclub.dev unless you choose another domain, and its name starts with "wel-". By default it also returns a fictional persona (first name, last name, username) to fill in sign-up forms; with age, the persona also gets a date of birth in that range, and with country, where it lives, for forms that ask. With password: true it also returns a strong password for the form, saved on the address; this is the only time it is shown here. It doesn't register anything in the app: sign up there yourself, or, if you can't open the app, give the person the address (and password) to sign up with. Then call wait_for_code or wait_for_link and pass on the code or link.

Input Schema

Name	Required	Description	Default
`age`	No	Give the persona a date of birth (persona.date_of_birth, YYYY-MM-DD) for this age: adult (18 to 65), over21, under18 (15 to 17), under15 (13 or 14), under13 (8 to 12), any (8 to 80), or someone who turns 18 tomorrow or turned 18 today. Leave out for none.
`name`	No	A custom name before the @. Random when left out. Generic names on their own (test, demo, info…) and words for running a mail domain (admin, postmaster…) are refused: add something of your own, such as test-acme.
`site`	No	Where the account is used: the host or a page URL of the app under test, such as staging.example.com or localhost:3000. Kept as the host.
`test`	No	With run_id: the test or step this call belongs to, shown beside what it saw in the report.
`label`	No	What it is for, such as the flow being tested.
`domain`	No	Mail domain. The project's default is mailclub.dev; choose another only if the app under test rejects it.	mailclub.dev
`run_id`	No	A run from start_run: what this call sees is added to its report.
`country`	No	Where the persona lives (persona.country), as an ISO 3166-1 alpha-2 code such as GB or US, for forms that ask or for testing location-based content. Leave out for none.
`persona`	No	Also generate a fictional first name, last name and username.
`password`	No	Also generate a strong password (16 characters: upper- and lower-case letters, digits and symbols) and save it on the address, for sign-up forms that ask for a password.
`environment`	No	Which environment of the app, such as staging, qa or local.
`date_of_birth`	No	A date of birth to use instead of age, YYYY-MM-DD.
`lifetime_days`	No	Days the address lasts, 1 to 30.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / name / description

Previous value: -"A custom name before the @. Random when left out."New value: +"A custom name before the @. Random when left out. Generic names on their own (test, demo, info…) and words for running a mail domain (admin, postmaster…) are refused: add something of your own, such as test-acme."

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / domain / enum

Previous value: -[
-  "mailclub.dev",
-  "enable.li"
-]New value: +[
+  "mailclub.dev",
+  "enable.li",
+  "valida.te.it"
+]

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / environment

Added value: +{
+  "description": "Which environment of the app, such as staging, qa or local.",
+  "maxLength": 40,
+  "type": "string"
+}

addedInput schema / properties / site

Added value: +{
+  "description": "Where the account is used: the host or a page URL of the app under test, such as staging.example.com or localhost:3000. Kept as the host.",
+  "maxLength": 300,
+  "type": "string"
+}

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (mutating, non-idempotent, not open-world), and the description adds the things annotations cannot: the generated address always has a "wel-" prefix, the password is shown only once at creation and is thereafter stored on the address, and the address lifetime is capped at 30 days. Those are the facts an agent needs to avoid losing credentials.

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?

It is front-loaded with the core action and the workflow follow-up, and every sentence is functional. It runs slightly long and restates a few details already in the schema (the 16-character password composition, the default domain), which keeps it from a 5.

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?

With 13 optional parameters and no output schema, the description must explain what comes back — and it does: the address, an optional persona, optional date of birth, optional country, and optional password. It also states the ownership boundary (it does not sign up for you) and the next step, leaving nothing an agent must guess before calling.

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 per-parameter meaning is already carried by structured data (baseline 3). The description earns above baseline by explaining cross-parameter dependencies the schema doesn't spell out: age adds a date of birth to the persona, country adds a residence, and password: true both returns and saves a password.

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 opens with a specific verb and resource ("Creates a disposable email address in the project") and immediately scopes it to the app under test and the @mailclub.dev domain. It also draws a hard line against sibling tools: it explicitly says it does not register anything in the app and routes the agent onward to wait_for_code or wait_for_link.

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?

It names the concrete workflow conditions — sign up yourself, or hand the address (and password) to the person if you can't open the app — and then names the follow-up tools to call. The domain parameter guidance ("choose another only if the app under test rejects it") is an explicit when/when-not rule as well.

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

All Proxy Mail QA 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.

Directories

Listed in ChatGPT · Proxy Mail QA

Last observed 2026-11-02

Resources

Need Help?