Agent Callback Mailbox

Temporary Authenticated A2A Callback Inbox

create_a2a_callback_mailbox

Create a temporary private authenticated webhook inbox for asynchronous A2A task completion. Let an expensive reasoning agent suspend instead of spending model calls polling for completion; a lightweight worker can receive and persist the callback, then resume the agent when useful data exists. One payment includes up to 1,000 ordered callback messages, replay-safe deduplication, cursor retrieval, a configurable 1-minute to 24-hour lifetime, and up to 4 MiB storage.

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": {
      "expectedTaskId": "<expectedTaskId>",
      "ingressCredential": "<ingressCredential>",
      "retrievalCredential": "<retrievalCredential>"
    },
    "name": "create_a2a_callback_mailbox"
  }
}

Input Schema

Name	Required	Description	Default
`maxBytes`	No
`maxEvents`	No
`ttlMinutes`	No
`expectedTaskId`	Yes
`ingressCredential`	Yes
`retrievalCredential`	Yes

Output Schema

Name	Required	Description	Default
`max_bytes`	Yes
`expires_at`	Yes
`mailbox_id`	Yes
`max_events`	Yes
`callback_url`	Yes
`authentication_scheme`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it discloses that the inbox is temporary, private and authenticated, capped at 1,000 ordered messages, replay-safe with deduplication, cursor-retrievable, and limited to a 1-minute to 24-hour lifetime and 4 MiB. Gaps remain on what happens at expiry (are messages lost, is the mailbox reusable) and on rate limits or pricing semantics beyond the single 'one payment' remark.

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?

Two sentences, front-loaded with the purpose before the operational details. The second sentence is dense but every clause is a distinct, useful fact (message cap, dedup, cursor retrieval, lifetime, storage). The 'One payment includes...' framing leans slightly promotional but does convey a cost characteristic.

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?

An output schema exists, so return shape need not be explained, and the description covers the lifecycle and limits that matter for a create operation. The remaining hole is credential semantics — an agent must guess which credential belongs on the ingress call versus the retrieval call, and nothing states whether retrieval consumes messages.

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 description coverage is 0% across six parameters, so the description must compensate, and it does for several: maxEvents maps to the 1,000 ordered messages, maxBytes to the 4 MiB storage cap, ttlMinutes to the 1- to 24-hour lifetime, and expectedTaskId is implied by the A2A task-completion framing. It does not explain the distinct roles of ingressCredential versus retrievalCredential, which is the most consequential ambiguity given both are required and look interchangeable.

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 opens with a specific verb and resource: "Create a temporary private authenticated webhook inbox for asynchronous A2A task completion." That is far more precise than the name alone, which relies on the opaque acronym 'a2a'. No siblings are listed, so there is no alternative to differentiate against, which keeps it just short of a 5.

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 a concrete usage scenario and rationale: let an expensive reasoning agent suspend rather than burn model calls polling, with a lightweight worker receiving and persisting the callback. This clearly implies when to reach for it. It stops short of explicit exclusions or named alternatives (e.g., when a plain polling loop or an existing webhook is preferable).

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

All Agent Callback Mailbox 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?