Skip to main content
Glama

manage_inbox

Create, read, delete, and audit receive-only email inboxes. action=create writes an address on the inbound domain and returns inbox plus address (ACL inbox_create). Requires an active plan. Temporary inboxes expire and purge. action=list returns active inboxes (ACL inbox_list). action=get returns one inbox (ACL inbox_get). action=delete deletes the inbox and purges stored messages (ACL inbox_delete). action=audit lists account audit entries (ACL inbox_audit_list). These calls do not meter; inbound mail later meters inbound_email. No outbound email. Use read_inbox_message for mail, manage_inbox_webhook for HTTPS notifications, and manage_inbox_blocklist for sender blocks.

Input Schema

NameRequiredDescriptionDefault
kindNotemporary expires after ttlSeconds (default 86400, max 604800 unless the deployment overrides those). permanent does not expire. Required for action=create. Omit otherwise.
limitNoPage size for action=audit. Default 50. Ignored by create, list, get, and delete.
actionYescreate checks ACL inbox_create and writes an inbox. list checks inbox_list. get checks inbox_get. delete checks inbox_delete and purges messages. audit checks inbox_audit_list. Required. No default.
domainNoInbound domain for action=create. Default is the deployment inbound domain. Must already be configured. Ignored by other actions.
offsetNoRow offset for action=audit. Default 0. Ignored by create, list, get, and delete.
inboxIdNoInbox id. Required for get and delete. Omit for create, list, and audit.
localPartNoAddress prefix before @domain. Required for action=create except on deployments with a fixed inbound email pool (QA), where omitting assigns the next free pool address. Stored lowercased. Omit for other actions.
ttlSecondsNoLifetime for kind=temporary. Default 86400 seconds. Ignored for permanent and for actions other than create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / localPart / description
      Previous value: -"Address prefix before @domain. Required for action=create. Stored lowercased. Omit for other actions."New value: +"Address prefix before @domain. Required for action=create except on deployments with a fixed inbound email pool (QA), where omitting assigns the next free pool address. Stored lowercased. Omit for other actions."
  2. Added

TDQS

A4.5/5.0
Behavior4/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: it discloses ACL scopes per action, the plan prerequisite, that delete purges stored messages, that temporary inboxes expire and purge, and that calls themselves do not meter but inbound mail meters inbound_email. It stops short of stating reversibility of delete, error behavior on an inactive plan, or whether list is paged.

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?

Purpose is front-loaded in the first sentence, then one clause per action, then cost and sibling routing. Dense but every sentence carries information; the ACL parentheticals make some clauses run long and could be trimmed.

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 an 8-parameter, five-action tool with no output schema and no annotations, this covers purpose, gating, destruction, cost, and alternatives. The remaining gap is return shape for list/get and whether list results are bounded, which matters more here because limit/offset apply only to audit.

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 action-level meaning beyond the schema by mapping each action to its ACL and noting that delete purges messages and create returns inbox plus address. It does not restate per-parameter detail, which the schema already supplies.

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?

Opens with a specific verb set and resource: "Create, read, delete, and audit receive-only email inboxes," and closes by naming each sibling it is not (read_inbox_message, manage_inbox_webhook, manage_inbox_blocklist). An agent can distinguish this tool from its neighbors without opening any 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?

States the selection rule for every action (action=create/list/get/delete/audit) and explicitly routes mail reading, HTTPS notifications, and sender blocks to the three sibling tools. Also gives the precondition (requires an active plan) and the exclusion (no outbound email).

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.