Skip to main content
Glama

Proxy Mail QA

Wait for a verification code

wait_for_code

Waits up to 30 seconds for a verification or login code to arrive at the address, and returns it with the sending service and when it expires. Returns at once if one arrived in the last 15 minutes. kind: coupon waits for a coupon or promo code instead (after signing up for an offer, say), with its discount and the date it is valid until when the email states them. With since, after_seconds says how long after it the email arrived; offers often come minutes later, so call again if nothing has come yet.

Input Schema

NameRequiredDescriptionDefault
kindNootp for a sign-in or verification code, coupon for a coupon or promo code, any for either.otp
testNoWith run_id: the test or step this call belongs to, shown beside what it saw in the report.
sinceNoOnly match email received at or after this time. Default: the last 15 minutes.
run_idNoA run from start_run: what this call sees is added to its report.
unusedNotrue: only a code or link nobody has used yet (not returned by an earlier wait, nor opened, copied or filled in the app or Proxy Mail QA for Chrome). For a second code without changing since.
addressYesA 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.
serviceNoOnly match email from this sender, by service name or domain (for example the name of the app under test).
timeout_secondsNoHow long to wait. 0 checks once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / unused / description
      Previous value: -"true: only a code or link nobody has used yet (not returned by an earlier wait, nor opened or copied in the app). For a second code without changing since."New value: +"true: only a code or link nobody has used yet (not returned by an earlier wait, nor opened, copied or filled in the app or Proxy Mail QA for Chrome). For a second code without changing since."
  2. Changed1 schema field changed
    • addedInput schema / properties / kind
      Added value: +{
      +  "default": "otp",
      +  "description": "otp for a sign-in or verification code, coupon for a coupon or promo code, any for either.",
      +  "enum": [
      +    "otp",
      +    "coupon",
      +    "any"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, so the description adds real value: the 30-second cap, the instant return for mail from the last 15 minutes, and the fact that 'unused' excludes codes already returned by an earlier wait (implying waits observe/consume state). It still doesn't say what a timeout or no-match response looks like, which matters for a tool flagged as not read-only.

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?

Three dense but purposeful sentences, front-loaded with the timeout and return shape before the kind and since variants. Nothing is redundant with the schema or the title.

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?

With 8 parameters and no output schema, the description still states the main return fields (code, sending service, expiry, after_seconds) and the timing behavior, which is what an agent needs to call it correctly. It falls short only on failure/timeout response shape and on the meaning of readOnlyHint=false.

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; the description earns more by explaining the since/after_seconds relationship and the retry implication, and by clarifying the coupon semantics of kind. Remaining params (test, service, unused, address variants) are only covered in 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?

States a specific verb and resource ('waits ... for a verification or login code') plus the scope variants (otp vs coupon vs any), so an agent knows exactly what arrives in the result. It never names the obvious sibling wait_for_link, so the code-vs-link routing decision is left to inference from the tool names.

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?

Gives concrete when-to-use context ('after signing up for an offer, say') and a retry rule ('offers often come minutes later, so call again if nothing has come yet'). It lacks an explicit exclusion, e.g. when to prefer wait_for_link or check_email/check_offers instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Directories

Listed in ChatGPT · Proxy Mail QA

Last observed

Resources