Proxy Mail QA

Check an email

check_email

Checks the newest matching email at the address (or email_id, from count_emails): SPF, DKIM and DMARC, links to localhost or plain http, where its sign-in, verify, reset or invite link goes (expect_host), whether it says when its sign-in code or link expires and when a coupon ends, a plain-text part, its size against Gmail's 102 KB limit, image-only emails, whether it fits a phone (fixed widths, alt text, tiny text), and, when asked, whether it contains given phrases (expect_text), is in a given language (expect_language) arrived soon enough after since (expect_within, such as 5m) and has the attachments expected (expect_attachment, such as .pdf). A marketing email also gets list_unsubscribe (a List-Unsubscribe header with an https address), one_click_unsubscribe (List-Unsubscribe-Post, covered by a DKIM signature that verified), unsubscribe_link (one in the email), preheader (preview text) and after_unsubscribe (it came after the address unsubscribed from its sender, see mark_unsubscribed); other emails skip them. A coupon also gets offer_reuse: it fails when the sender already sent a coupon to another version of the address (name+promo1@…, capitals); and coupon_result, once record_coupon_result has said what checkout did with it. Marketing email is also judged by the rules where the persona lives (see record_consent): marketing_consent, prechecked_consent, double_opt_in, unsubscribe_deadline, postal_address, sender_identity, minor_marketing, misleading_subject (a fake Re: or a deadline the email contradicts) and ad_label (Singapore's ). Every email also gets harmful_attachment (a file type Gmail blocks, such as .exe or a program named like a .pdf, fails; macros, HTML pages and archives warn) and spam_risk, a spam score out of 10 (score, with the markers that add up to it) of whether inboxes would reject it or file it as spam (5 or more fails), might (1.5 or more warns) or wouldn't (pass). Each check passes, fails, warns or is skipped, with a one-line reason. Verdicts only: never the email's text or links. Wait for the email first. The marketing and coupon checks need Marketing and offer emails, and harmful_attachment and spam_risk need Spam score and attachment checks, switched on in Account settings → Labs; checks of a feature that's off are left out.

Input Schema

Name	Required	Description
`test`	No	With run_id: the test or step this call belongs to, shown beside what it saw in the report.
`type`	No	Only emails with a code, or with a link.
`since`	No	Only email received at or after this time, such as when the test submitted the form.
`run_id`	No	A run from start_run: what this call sees is added to its report.
`address`	Yes	A test address in this project. A variant works too (capitals, or a +tag such as name+o'brien@…): it acts on the plain address, and a wait on a +tag variant only finds mail sent to it.
`service`	No	Only email from this sender, by service name or domain.
`subtype`	No	With type, comma-separated: otp or coupon for codes; verify, magic_signin, invite, reset, other, unsubscribe or list_unsubscribe for links; or any (for links, the sign-in kinds and other).
`category`	No	Only sign-in emails (auth), receipts and notices (transactional), or offers and newsletters (marketing). For "an unsubscribed user gets no marketing", use marketing: receipts should still arrive.
`email_id`	No	The email to check, as count_emails gives it. Default: the newest that matches.
`expect_host`	No	The site its links should go to, such as staging.example.com (subdomains count). Without it, that check is skipped. Links to a host marked with mark_dev_host pass the local-links check.
`expect_text`	No	Phrases the subject or body should contain, such as the user's first name. Case, curly quotes and spacing don't matter. The answer names only the missing ones.
`expect_within`	No	With since: how soon after it the email should arrive, such as 90s, 5m or 2h (arrival_time). For a coupon after signing up for an offer, say.
`expect_language`	No	The language it should be in, such as de or pt-BR.
`expect_attachment`	No	Attachments it should have: a type (application/pdf, image/), an extension (.ics) or a file name with (invoice-*.pdf). The answer names only the missing patterns.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "Only sign-in emails (auth), receipts and notices (transactional), or offers and newsletters (marketing). For \"an unsubscribed user gets no marketing\", use marketing: receipts should still arrive.",
+  "enum": [
+    "auth",
+    "transactional",
+    "marketing"
+  ],
+  "type": "string"
+}

addedInput schema / properties / expect_attachment

Added value: +{
+  "description": "Attachments it should have: a type (application/pdf, image/*), an extension (.ics) or a file name with * (invoice-*.pdf). The answer names only the missing patterns.",
+  "items": {
+    "maxLength": 100,
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

addedInput schema / properties / expect_within

Added value: +{
+  "description": "With since: how soon after it the email should arrive, such as 90s, 5m or 2h (arrival_time). For a coupon after signing up for an offer, say.",
+  "type": "string"
+}

changedInput schema / properties / subtype / description

Previous value: -"With type, comma-separated: otp or coupon for codes; verify, magic_signin, invite, reset or other for links; or any."New value: +"With type, comma-separated: otp or coupon for codes; verify, magic_signin, invite, reset, other, unsubscribe or list_unsubscribe for links; or any (for links, the sign-in kinds and other)."

Changed1 schema field changedOct 18, 2026

changedInput schema / properties / expect_host / description

Previous value: -"The site its links should go to, such as staging.example.com (subdomains count). Without it, that check is skipped."New value: +"The site its links should go to, such as staging.example.com (subdomains count). Without it, that check is skipped. Links to a host marked with mark_dev_host pass the local-links check."

First observedOct 18, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that verdicts only are returned ('never the email's text or links'), that each check yields pass/fail/warn/skipped with a one-line reason, and that checks for disabled features are omitted. It doesn't contradict the annotations (readOnlyHint=false is consistent with the description's 'added to its report' via run_id).

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

Conciseness2/5

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

The description is a single enormous run-on sentence densely packed with every possible check, making it nearly impossible to scan. While the first clause is front-loaded, the rest is an undifferentiated wall of detail with no grouping or bullets, violating conciseness and structure.

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

Completeness4/5

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

For a complex 14-parameter tool with no output schema, the description is quite complete: it explains the verdict model, the gating by Labs settings, the reporting side effect, and the meaning of major checks. It is comprehensive but so dense that an agent may struggle to extract the key info efficiently.

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 the baseline is 3, but the description adds operational meaning: expect_host controls the link-destination check and is skipped without it, expect_text reports only missing phrases, expect_within works with since (e.g., 5m), and expect_attachment accepts types, extensions, or wildcards. This is more than repeating the schema.

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 opening clause gives a specific verb and resource ('Checks the newest matching email at the address (or email_id, from count_emails)') and enumerates the checks performed. It is clear what the tool does, but it never directly contrasts itself with siblings like wait_for_code, wait_for_link, or check_delivery, so an agent must infer the boundary.

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?

'Wait for the email first' states the key precondition, and the Labs feature gating (marketing/coupon checks, harmful_attachment and spam_risk) tells the agent when certain checks will be absent. It does not explicitly name alternatives or say when NOT to use it, but the practical usage context is clear.

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?