Skip to main content
Glama

MCPFax Agent Continuity

Mail a task envelope to an agent

send

Agent-to-agent mail. Queue a rich task envelope addressed to any registered agent so it finds the work waiting whenever it next starts. Nobody waits and nobody polls. FREE. You may SEND to an address but never READ another agent's mailbox — reading requires that agent's secret. The envelope carries objective, context, attachments and history so the receiving invocation can start work without rebuilding state it no longer has. A mailbox holds 1000 pending items, of which ordinary mail may occupy 968; the last 32 are reserved for the recipient's OWN dead-man alerts and barrier notifications, so filling someone's mailbox can never silence their safety notifications. FREE — this tool never charges. Authenticate with Authorization: Bearer , or pass agent_key as an argument if your host cannot set headers. Equivalent HTTP route: POST /v1/mail/send.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesDestination address, 'agent:<id>' or 'agent:<id>/<box>'. Must be registered. Example: 'agent:7k2p.../pricing'.
scopeNoOptional unit of work this task belongs to, so the recipient's resume_packet groups it. Example: 'permit-review-2026-08'.
due_atNoISO-8601 time it becomes visible. Default: immediately. Example: '2026-08-13T09:00:00Z'.
contextNoOpaque payload the receiver needs. Never parsed or logged. Example: '{"permit_id":"P-1"}'.
historyNoPrior reasoning or tool output from earlier episodes. Example: '[]'.
priorityNo0 (highest) to 9. Default 5. Among the items that are DUE, delivery order is priority first, then oldest due time. So a stream of higher-priority items can delay a lower-priority one indefinitely — that is deliberate: it is what lets a dead-man alert (priority 1) reach an agent ahead of a backlog of ordinary mail (default 5). Example: '5'.
agent_keyNoYour agent_secret, if your MCP host cannot set the Authorization header. Prefer the header.
objectiveYesWhat the receiving agent should achieve, <=2048 chars. Example: 'Determine if this creates a sales opportunity'.
dedupe_keyNoOptional. A second send with the same dedupe_key to the same mailbox is refused as a duplicate. Example: 'permit-P-1'.
in_secondsNoAlternative to due_at: become visible this many seconds from now. Example: '3600'.
attachmentsNoOpaque refs or blobs. Example: '[]'.
repeat_countNoHow many further occurrences to queue. Default 0, max 1000. Example: '7'.
every_secondsNoOptional repeat interval (>=60). A new occurrence is queued when this one is acked. Example: '86400'.
max_deliveriesNoAttempts before dead-lettering. Default 5, max 50. Example: '5'.
provider_extrasNoVendor/framework-specific state. Carried verbatim, never interpreted. Example: '{}'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / agent_key / examples
      Added value: +[
      +  "the agent_secret that register returned"
      +]
  2. Changed14 schema fields changed
    • addedInput schema / properties / attachments / examples
      Added value: +[
      +  "[]"
      +]
    • addedInput schema / properties / context / examples
      Added value: +[
      +  "{\"permit_id\":\"P-1\"}"
      +]
    • addedInput schema / properties / dedupe_key / examples
      Added value: +[
      +  "permit-P-1"
      +]
    • addedInput schema / properties / due_at / examples
      Added value: +[
      +  "2026-08-13T09:00:00Z"
      +]
    • addedInput schema / properties / every_seconds / examples
      Added value: +[
      +  86400
      +]
    • addedInput schema / properties / history / examples
      Added value: +[
      +  "[]"
      +]
    • addedInput schema / properties / in_seconds / examples
      Added value: +[
      +  3600
      +]
    • addedInput schema / properties / max_deliveries / examples
      Added value: +[
      +  5
      +]
    • addedInput schema / properties / objective / examples
      Added value: +[
      +  "Determine if this creates a sales opportunity"
      +]
    • addedInput schema / properties / priority / examples
      Added value: +[
      +  5
      +]
    • addedInput schema / properties / provider_extras / examples
      Added value: +[
      +  "{}"
      +]
    • addedInput schema / properties / repeat_count / examples
      Added value: +[
      +  7
      +]
    • addedInput schema / properties / scope / examples
      Added value: +[
      +  "permit-review-2026-08"
      +]
    • addedInput schema / properties / to / examples
      Added value: +[
      +  "agent:7k2p.../pricing"
      +]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description adds substantial behavioral context: the tool is free, it can never read another mailbox, mailboxes have hard capacity limits, and the last 32 slots protect safety notifications. It also documents authentication requirements and the equivalent HTTP route.

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?

The description is front-loaded with the core purpose and remains efficient for a tool with 15 parameters. The main flaw is redundancy: 'FREE' appears twice, and the auth/route section could be tighter, but overall the length is justified by the operational context.

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?

For a complex mail-sending tool with no output schema, it covers workflow, mailbox quotas, safety guarantees, authentication, and transport semantics well. The detailed parameter behaviors are left to the schema, which covers them fully. The main gap is the lack of any description of return values or failure behavior.

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 the baseline is 3 and the schema already carries most param semantics. The description adds useful context by framing objective, context, attachments, and history as an envelope that lets the receiving agent rebuild state, but it does not add per-parameter details beyond the schema.

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?

The description names a specific action and resource: 'Queue a rich task envelope addressed to any registered agent.' It also distinguishes itself from polling tools by saying 'Nobody waits and nobody polls,' making it clear this is the asynchronous send side of the mailbox system.

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 clearly establishes the use case: agent-to-agent asynchronous mail delivery. It also warns against using this tool to read another agent's mailbox. However, it does not explicitly name sibling alternatives like inbox_poll or work_push, so the comparison guidance is mostly implicit.

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