WritersLogic agent-infra

inbox-poll

Read messages from a receive-only agent inbox — Returns the emails and webhook deliveries that arrived in an inbox you created with inbox-create, oldest first, with sender, subject, selected headers, a plain-text body (up to 64 KB per message in the response) and a sha256 of the stored body. Filter by since (inclusive), kind, limit up to 100; mark_consumed hides the returned messages from later polls unless include_consumed is true. It does not

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": {
      "inbox_id": "<inbox_id>"
    },
    "name": "inbox-poll"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Default all.
`limit`	No	Default 50.
`since`	No	Only messages received at or after this time: epoch milliseconds or ISO 8601 (UTC when no offset). Inclusive, so dedupe by id or use mark_consumed.
`inbox_id`	Yes
`tenantId`	No	Required for API-key callers (namespace as key:<tenantId>; keep it unguessable). Ignored when a wallet paid.
`mark_consumed`	No	Mark the returned messages consumed. Default false.
`include_consumed`	No	Also return consumed messages. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does well on several fronts: it discloses the 64 KB per-message body cap, a sha256 of the stored body for verification, oldest-first ordering, and the non-obvious side effect that mark_consumed suppresses messages from later polls. It does not cover auth requirements, rate limits, or what happens on an unknown/expired inbox_id, and the final truncated sentence suggests a caveat was lost.

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 opening sentence is well front-loaded and dense with useful detail, but the description ends mid-sentence ('It does not'), leaving a dangling fragment that is pure waste and signals a broken definition. Otherwise there is little filler.

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 7-parameter read tool with no output schema and no annotations, the description covers the return shape, ordering, size limits, and consumption semantics well. Gaps remain around authentication expectations, error behavior for missing inboxes, and the truncated trailing caveat.

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 86%, so the baseline is 3, but the description genuinely adds meaning: since is inclusive with a dedupe implication, limit caps at 100, and crucially the mark_consumed / include_consumed interaction is explained in a way the schema alone does not convey. inbox_id format and tenantId namespacing are left entirely to 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?

Names a specific verb and resource (read messages from a receive-only agent inbox) and immediately distinguishes it from the creation sibling by citing inbox-create. The returned payload is enumerated concretely (sender, subject, headers, plain-text body, sha256), so an agent knows exactly what it gets back.

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?

Clear operational context: use it on an inbox you created with inbox-create, oldest first, with explicit guidance to dedupe by id because since is inclusive. It lacks a stated when-not-to-use clause, and the one sentence that appears to have been the exclusion ('It does not') is cut off, so the boundary case is left unstated.

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

All WritersLogic agent-infra 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?