Letter IRL

Get a link to send a preview

request_send

Read-only

Get a link where the person checks a previewed letter or postcard and sends it themselves on letterirl.com: they press Send on that page, or pay there with Pay & Send for mail no letter pack pays for. Use it when the person wants to send a preview and no preview card with a Send button is showing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "draftId": "<draftId>"
    },
    "name": "request_send"
  }
}

Input Schema

Name	Required	Description	Default
`draftId`	Yes	The draftId from a letter or postcard preview

Output Schema

Name	Required	Description
`draftId`	Yes
`mailType`	Yes
`schedule`	No	The preview's arrival dates, YYYY-MM-DD: once sent, it waits until its mail date
`mailService`	No	Present only when the letter goes as certified mail: certified, or certified_return_receipt (with an electronic return receipt). Paid with Pay & Send.
`paidPerSend`	No	Present when the person pays for it with Pay & Send on that page: letter packs and gift letters pay only for one-page letters and 6x9 postcards, and never for certified mail
`expiresAtISO`	Yes
`confirmationUrl`	Yes	Where the person checks the preview and sends it themselves
`recipientSummary`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.6/5.0

Behavior3/5

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

The annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the link does (the user presses Send or pays via Pay & Send, no letter-pack charge), but says nothing about link lifetime, single-use behavior, or what state the draft is in afterwards.

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

Conciseness3/5

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

The core intent is front-loaded in the first clause, but the sentence is long and contains awkward phrasing ('on letterirl.com', 'for mail no letter pack pays for') that costs a read to parse. It is not padded with filler, but it is harder to scan than it needs to be.

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 an output schema present, the description need not explain the returned link, and one fully documented parameter keeps the surface small. What remains thin is the lifecycle detail — whether the link expires, is reusable, or whether the agent should poll get_draft_status after the user acts.

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% for the single draftId parameter, so the schema already carries the semantics. The description only loosely corroborates by referring to 'a previewed letter or postcard,' adding no format or sourcing detail beyond 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 description uses a specific verb ('Get a link') and resource (previewed letter/postcard) and makes clear that the human, not the agent, ultimately presses Send. It implicitly separates itself from send_letter/send_postcard by describing the self-serve handoff, though it never names those siblings 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?

It gives an explicit trigger: 'Use it when the person wants to send a preview and no preview card with a Send button is showing.' That is a clear when-to-use condition, but there are no stated exclusions or named alternatives (e.g. 'use send_letter if you have authorization to send directly').

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

All Letter IRL 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.

Resources

Need Help?