Skip to main content
Glama
mailsocket

mailsocket

Official
by mailsocket
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

send_test_code

Inject a sample 6-digit OTP email into an inbox so you can test OTP wait flows when no real email has arrived.

Instructions

Put one sample OTP email (a random 6-digit code) into inbox_id.

Use this to check the wait loop end to end when you have no real email
to trigger. It does NOT go through the mail server: the message is
stored and parsed exactly like real inbound mail, so ``wait_for_otp``
returns it.

How to pair it with the wait (one call at a time, no concurrency):
BEFORE calling this tool, take a cutoff, either the ``id`` of the newest
message (``get_latest``; use ``since=0`` if the inbox is empty) or the
current time (ISO8601 or unix seconds). Then call ``send_test_code``,
then ``wait_for_otp(inbox_id, since=<that cutoff>)``. Without ``since``,
the wait only matches mail arriving during the wait itself and would
miss this code. Do not pass the returned ``message_id`` as ``since``:
that means "after this message" and skips it.

Limits: 5 per inbox and 20 per account per hour (shared with the
dashboard "Send a test code" button); over that, a clean rate-limit
error says when to retry. A disabled inbox, or an unknown/deleted/
foreign inbox id, returns a clean tool error and nothing is charged.

Side effects: creates one message in the inbox (counts toward monthly
message usage and fires the inbox's webhook, like real mail). Makes one
network call to the mailsocket API (``openWorldHint``). Returns
``message_id`` and ``sent_at`` of the new message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inbox_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

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 (openWorldHint, non-idempotent), and the description goes well beyond them: rate limits (5/inbox, 20/account per hour, shared with the dashboard button), error behavior for disabled/unknown/deleted/foreign inboxes, side effects (counts toward monthly usage, fires the webhook), and the single network call. This is unusually rich behavioral disclosure.

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?

Front-loaded with the core action, then limits and side effects, with the pairing procedure broken out clearly. It is longer than typical, and the multi-step pairing paragraph could be tightened, but every section (limits, errors, side effects, return values) carries information an agent needs.

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?

For a one-parameter mutation tool with no output schema, the description supplies everything needed: when to use it, how to sequence it with wait_for_otp, rate limits, error cases, side effects, and the return fields (message_id, sent_at). Nothing material is missing.

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?

There is one parameter with 0% schema description coverage, so the description carries the burden. It clarifies inbox_id semantics indirectly by describing which inbox states are invalid (disabled, unknown, deleted, foreign) and by tying the tool to get_latest/wait_for_otp cutoffs, but it never states the id format or where to obtain it beyond naming get_latest.

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 action (inject one sample OTP email with a random 6-digit code) and the exact target (inbox_id), and explicitly says it does not go through the mail server, distinguishing it from real inbound mail and from the wait tools. An agent can identify the tool and its scope without opening the schema.

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?

Gives explicit when-to-use ('when you have no real email to trigger'), names the sibling it pairs with (wait_for_otp), and spells out the required call ordering and the cutoff/since mechanics. It also warns against the failure mode of passing the returned message_id as since, which is exactly the kind of exclusion that prevents misuse.

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

Deploy Server

Other Tools