Skip to main content
Glama

MCPFax Agent Continuity

by com.mcpscores

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: '{}'.

TDQS

A4.3/5.0
Behavior4/5

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

With all annotations false (readOnlyHint, idempotentHint, destructiveHint), the description carries the burden of disclosing effects, and it does so substantially. It states the tool never charges ('FREE'), queues rather than delivers synchronously, respects mailbox capacity limits ('968 ordinary items + 32 reserved for safety alerts'), and guarantees safety notifications cannot be silenced by flooding. It also discloses authentication requirements (Bearer header or agent_key). This goes well beyond the annotations.

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 a clear purpose statement and then expands into relevant details. It is efficient but has minor redundancy: 'FREE.' appears twice ('FREE.' and 'FREE — this tool never charges.'). It is longer than strictly necessary but every other sentence earns its place, covering safety, capacity, and authentication.

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 tool with 15 parameters, no output schema, and all-false annotations, the description is remarkably complete. It covers the core behavior, cost model, capacity limits, safety guarantees, and authentication. The only notable omission is the return value or outcome of a successful send (e.g., whether it returns a message ID or ack), which would help since there is no output schema. Still, the description gives the agent enough to use the tool correctly.

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?

Schema coverage is 100% with descriptions for all 15 parameters, so the baseline is 3. The description adds extra meaning by explaining the envelope's purpose: 'The envelope carries objective, context, attachments and history so the receiving invocation can start work without rebuilding state it no longer has.' This gives semantic rationale for several parameters that the schema alone does not convey. It doesn't cover every parameter, but the schema already does that, so 4 is appropriate.

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 opens with 'Agent-to-agent mail' and immediately defines the action: 'Queue a rich task envelope addressed to any registered agent.' This names the verb (queue/send), the resource (task envelope), and the delivery model (asynchronous mailbox), clearly distinguishing it from sibling tools like inbox_poll or work_push. It also explicitly states what the tool does NOT do: 'You may SEND to an address but never READ another agent's mailbox.'

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?

The description gives clear context for when to use send: when you need to deliver work to another agent asynchronously, with 'Nobody waits and nobody polls.' It also provides a usage exclusion: 'You may SEND to an address but never READ another agent's mailbox — reading requires that agent's secret.' However, it does not explicitly name alternative tools (like inbox_poll or inbox_ack) as the rubric's top tier requires, so it falls short of a 5.

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

All MCPFax Agent Continuity toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Every tool targets a clearly distinct mechanism—barriers, budgets, checkpoints, claims, heartbeats, inboxes, leases, work queues, etc. Even closely related pairs like claim/complete, work_done/inbox_ack, and barrier_status/work_status are explicitly differentiated in their descriptions, so an agent can reliably select the right tool.

Naming Consistency4/5

The dominant pattern is object_verb (e.g., checkpoint_get, work_push, seen_add, lease_release), which is consistent and readable. A few single-word verbs (claim, complete, send) and noun-only names (resume_packet, retry_state, whoami) break the pattern, but they are few and still intuitive.

Tool Count2/5

With 33 tools, the surface is well beyond the 25-tool threshold for 'too many' and will feel heavy for agents to explore, even though the tools are organized into subdomains. The scope is broad, but the sheer number makes the server less approachable and increases the chance of misselection.

Completeness5/5

The tool set provides thorough lifecycle coverage across its domains: checkpoints get/put, work queue push/take/done/fail/status, inbox poll/ack/nack/schedule, lease acquire/renew/release, barrier create/signal/status, dedup add/check, watermark get/set, retry state, budget check/record, and idempotency claim/complete. There are no obvious dead ends or missing essential operations.

Resources