Skip to main content
Glama

Change how a letter travels

set_mail_service
Idempotent

Change how a previewed letter travels without previewing it again: standard (ordinary first-class mail), certified (USPS Certified Mail) or certified_return_receipt (Certified Mail with an electronic return receipt). Only when the person asks to add or remove certified mail: it costs more and is paid with Pay & Send, never a letter pack or a gift letter, and a postcard or a gift letter cannot be certified. Give the draftId from the preview and mailService; the page does not change, its price does.

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>",
      "mailService": "<mailService>"
    },
    "name": "set_mail_service"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftIdYesThe draftId from a letter preview
mailServiceYesHow the letter travels: standard (ordinary first-class mail), certified (USPS Certified Mail) or certified_return_receipt (Certified Mail with an electronic return receipt). Certified mail costs more and is paid with Pay & Send: no letter pack and no gift letter pays for it.

Output Schema

NameRequiredDescriptionDefault
pagesNoPresent only for a letter of more than one page: the pages it prints on, both sides of the paper. No letter pack or gift letter pays for it; it is paid with Pay & Send.
draftIdYes
messageYes
canSendNowYesWhether the balance or a gift letter pays for the letter as it is now: certified mail is paid with Pay & Send, so it is false for it
mailServiceNoPresent only when the letter now goes as certified mail: which service. Absent: an ordinary letter
deliveryClassNoWith the terms, for a letter that is certified mail or while certified mail is offered, and for a sent letter: how it is delivered, as a new preview would say it. A card draws it on its Delivery line
contentVersionNoThe version of this mail as it is now: send it with the send, so what is mailed is what the person saw
sendEligibilityYes
reasonCannotSendNo
deliveryDisclaimerNoWith it, the words that qualify the delivery
contentVersionBeforeNoThe version of this mail the change was made to: for the preview card, which takes contentVersion only when this is the version it shows

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (non-destructive, idempotent, not read-only), and the description goes further by disclosing cost implications, the payment constraint (no letter pack or gift letter), and that postcards and gift letters cannot be certified. It also clarifies the side effect on the preview ('the page does not change, its price does'). Nothing contradicts the annotations, though the interaction with an existing draft beyond price is lightly treated.

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 action and the no-re-preview guarantee, then constraints. Slightly dense with repeated enum parentheticals that duplicate the schema, but no sentence 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?

For a two-parameter mutation tool with an output schema and full annotation coverage, the definition supplies the outstanding context: cost, payment method, eligibility exclusions, and the fact that the preview itself is unchanged. Nothing an agent needs to invoke 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 coverage is 100% and both parameters already carry descriptions, including the identical mailService enum explanation. The description's 'Give the draftId from the preview and mailService' restates the schema rather than adding syntax or format detail, so the baseline of 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 ('Change how a previewed letter travels') plus the key qualifier 'without previewing it again', which separates it from the quote_and_preview_letter siblings. The three allowed values are enumerated inline, so an agent knows exactly what the tool operates on.

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 an explicit gating condition: 'Only when the person asks to add or remove certified mail'. It also names the consequence (costs more, paid with Pay & Send) that selects the alternative path, so the agent can decide when not to use it.

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.

Resources