Skip to main content
Glama
Sign In

mailbox.bot

by bot.mailbox
OverviewDiscussionsAdmin

advance_test_batch_mail

Sandbox keys only: simulate the facility one step (submitted → in_progress → completed). Completion marks every piece mailed and fires batch.completed to the agent's webhook, exactly as the facility would. With qr_event and piece it records a scan or a confirmation on that piece of a sandbox batch with QR codes instead, as if a phone scanned it, and the batch.piece.* webhooks fire. Live batches are advanced by the facility, never by the API.

Input Schema

NameRequiredDescriptionDefault
pieceNoThe piece (1-based) for qr_event.
batch_idYesThe batch's id (UUID) from create_batch_mail or list_batch_mail.
qr_eventNoRecord a scan or a confirmation instead of advancing the batch.

Output Schema

NameRequiredDescriptionDefault
resultYesbatch, previous_status, sandbox true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / piece
      Added value: +{
+  "description": "The piece (1-based) for qr_event.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / qr_event
      Added value: +{
+  "description": "Record a scan or a confirmation instead of advancing the batch.",
+  "enum": [
+    "scan",
+    "confirm"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: completion marks every piece mailed and fires batch.completed, and the QR path fires batch.piece.* webhooks. That side-effect disclosure is valuable for a non-readOnly, non-destructive, non-idempotent tool. It stops short of saying what a repeat call does at the terminal 'completed' state, so idempotency behavior is left implicit.

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-loads the most decision-relevant fact ('Sandbox keys only') and covers both modes in three sentences with no filler. The middle sentence is densely packed, requiring a second read to separate the two modes, which keeps it out of top marks.

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 3-parameter mutation tool with an output schema and full annotations, the description covers scope restriction, state transitions, webhook side effects, and the alternate QR mode. 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: qr_event and piece act together as an alternative mode rather than modifiers on the advance behavior. It doesn't add format or validation details beyond the enum and 1-based note already in 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?

States a specific verb and resource ('simulate the facility one step' on a test batch) and spells out the state machine submitted → in_progress → completed. It also clearly delineates a second mode (qr_event + piece records a scan/confirm rather than advancing), so an agent can tell 'advance' from 'record a QR event' without opening the schema.

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 precondition ('Sandbox keys only') and an explicit exclusion ('Live batches are advanced by the facility, never by the API'), which is exactly the when-not guidance an agent needs. It also states the condition that selects the alternate mode ('With qr_event and piece...instead').

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

All mailbox.bot toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources