tossinbox
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TOSSINBOX_STATE | No | Override the local state file path (default: ~/.tossinbox/state.json). Contains provider tokens and is written with 0600 permissions. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_inboxA | Create a brand new disposable email inbox. The inbox is saved locally so the other tools can use it. Returns the full email address to use in sign-up forms. |
| list_messagesA | List the messages currently in a disposable inbox (defaults to the most recently created inbox). |
| read_messageA | Read the full body of a message by id, including any verification code detected in it. Lists attachment metadata; pass save_dir to also save the attachments and the HTML body to disk (where the provider supports downloads). |
| wait_for_codeA | Poll a disposable inbox until a message arrives, then return the verification code (OTP) found in it. Ideal right after submitting a sign-up form. Times out gracefully. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: create, list, read, and wait-for-code. There is no functional overlap between them.
All tool names follow a consistent verb_noun pattern: create_inbox, list_messages, read_message, wait_for_code. The naming is uniform and predictable.
Four tools is an ideal size for a disposable inbox service. Each tool covers a necessary step in the workflow without redundancy or bloat.
The core lifecycle is well covered: creation, listing, reading, and polling for codes. A minor gap is the lack of an explicit delete_inbox or get_inbox, but these are not essential for the stated purpose.