Skip to main content
Glama

Restore mailbox

restore_mailbox

Bring back an address you created earlier and deleted, e.g. to receive a password reset for an account you signed up with. Find it with search_deleted_mailboxes. It comes back empty (old emails are gone). Only your own addresses on domains still in service can be restored. Counts as a new mailbox for your limits. Returns a new mailbox id (mbx_…); the old id stays invalid, so use the returned id or the address.

Input Schema

NameRequiredDescriptionDefault
addressYesThe full address, e.g. kavor-otter-4821@domain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations: discloses that restored mailboxes are empty, that only own addresses on in-service domains qualify, that it consumes a new mailbox slot against limits, and that the old id is permanently invalidated in favor of the returned id. These are exactly the mutation side effects an agent needs and none are contradicted by 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, front-loaded with purpose, then discovery route, then caveats, then return-value contract. Every sentence carries distinct information with no padding.

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?

No output schema exists, and the description compensates by specifying the return value (a new mbx_ id) and the id-invalidation rule. Combined with the limit-counting and emptiness caveats, an agent has everything needed to call this 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 a format example for address, so the baseline is 3. The description adds real semantic constraints on the value beyond the schema: it must be an address you own and on a domain still in service.

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?

Specific verb+resource with scope: 'Bring back an address you created earlier and deleted' clearly distinguishes restore from create_mailbox and delete_mailbox. The example use case (receiving a password reset) further pins down intent.

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?

Explicitly routes the agent to search_deleted_mailboxes to locate the target, and warns that the mailbox comes back empty so the agent doesn't expect old emails. There is no explicit when-not-to-use or statement about preconditions being required beyond the 'own domain still in service' constraint.

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.

Resources