tmailor-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Wait for an email (OTP, verification link)

wait_for_message

Wait for a new unread email matching filters and return its OTP code, links, and text; use after sign-up to capture verification messages before timeout.

Instructions

Return the newest UNREAD message matching the filters, or wait until one arrives.

The result includes otp (the one-time code found in the message, or null), codes, links and the text. Returning a message marks it as read, so the next call waits for the next one. If nothing arrives in time, status is "timeout": call again if the email may still come (for example the sign-up was just submitted).

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	The email address, as returned by create_mailbox or list_mailboxes.
`max_chars`	No	Maximum characters of message text to return (longer text is cut).
`from_contains`	No	Only messages whose sender name or address contains this text.
`timeout_seconds`	No	How long to wait for a new message.
`subject_contains`	No	Only messages whose subject contains this text.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`email`	Yes
`status`	Yes
`message`	No
`message_id`	No
`waited_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Discloses the key non-obvious side effect that explains the annotation profile (readOnlyHint=false, idempotentHint=false): 'Returning a message marks it as read, so the next call waits for the next one.' It also explains the timeout/status contract and the retry expectation, which annotations alone cannot convey.

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 short chunks, front-loaded with the core behavior and then the side effect and the timeout remedy. Every sentence carries operational information; nothing is filler.

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 an output schema present the description is not obliged to enumerate return fields, yet it still names otp/codes/links/status because they drive the agent's next action, and it covers the read-marking side effect and retry loop. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters (email, max_chars, from_contains, timeout_seconds, subject_contains) are already documented in the schema. The description only echoes filter behavior generically ('matching the filters') without adding syntax or format detail, so baseline 3 applies.

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?

States a specific verb-and-resource with scope: 'Return the newest UNREAD message matching the filters, or wait until one arrives.' An agent can distinguish it from list_messages and read_message purely from this sentence, and the blocking/waiting semantics are named explicitly.

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 clear usage context: it is the polling/waiting variant, and on a 'timeout' status the agent should call again if the email may still arrive. It does not, however, contrast itself with list_messages or read_message for the non-blocking case, so the when-not guidance is only implicit.

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

Deploy Server