MCP server for Blip disposable email. Create inboxes, receive emails, and extract OTP codes — all from your AI agent.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"blip": {
"command": "npx",
"args": ["-y", "@useblip/email"],
"env": {
"BLIP_API_KEY": "blip_ak_..."
}
}
}
}claude mcp add blip -- npx -y @useblip/emailSet your API key:
export BLIP_API_KEY=blip_ak_...Run the server directly:
BLIP_API_KEY=blip_ak_... npx @useblip/emailRelated MCP server: UnCorreoTemporal
Sign in at app.useblip.email
Subscribe to the Agent tier
Create an API key from the dashboard
Tool | Description |
| Create a disposable email inbox with optional custom slug, domain, and TTL |
| List all active inboxes |
| Get inbox details and list of received emails |
| Read full email content (body, headers, attachments) |
| Extract OTP codes and verification links from the latest email |
| Poll until an email arrives (configurable timeout, default 60s) |
| Delete an inbox and all its emails |
"Create a disposable email and sign up for example.com, then give me the verification code"
"Make an inbox, wait for the password reset email, and extract the link"
"List my active inboxes and show me the latest emails"
Variable | Required | Default | Description |
| Yes | — | Your Blip API key |
| No |
| API base URL (for self-hosted) |
Create a new disposable email inbox. Returns the inbox ID and email address.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Custom address slug (e.g. 'mytest' for mytest@useblip.email) | |
| domain | No | Email domain (defaults to useblip.email) | |
| ttl_minutes | No | How long the inbox should live, in minutes (AGENT tier only, max 90 days). Defaults to 60 minutes if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool returns an ID and email but omits important traits such as whether the operation is idempotent, what happens on duplicate slug, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two brief, front-loaded sentences with no unnecessary words. Every sentence contributes core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage, the description lacks guidance on default behavior for optional parameters (e.g., what happens if slug is omitted), error conditions, and lifecycle details. Given 3 optional parameters and no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not enhance parameter meaning beyond the schema; it only mentions the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'create' and specifies the resource 'disposable email inbox'. It explicitly states the return values (inbox ID and email address), distinguishing it from sibling tools like delete_inbox, get_inbox, or list_inboxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to create vs. reuse an existing inbox). It does not mention prerequisites or conditions like slug uniqueness or domain validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an inbox and all its emails.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | The inbox ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion cascades to all emails, which is a critical behavioral trait. However, it omits other behavioral aspects like idempotency, error handling, or permission requirements. With no annotations, the description carries the full disclosure burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the purpose. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description is mostly complete, specifying both the primary action and the cascading effect. It lacks details on return values or error states, but the core functionality is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'inbox_id' parameter already well-documented. The description adds no extra semantic value beyond the schema's 'The inbox ID to delete', so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (inbox), and explicitly mentions the cascading effect on emails, distinguishing it from sibling tools like create_inbox or list_inboxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use or not use this tool, nor any mention of prerequisites or alternatives. The description only states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract OTP codes and verification links from the most recent email in an inbox. Use this after creating an inbox and receiving a verification/signup email.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | The inbox ID to extract codes from (uses most recent email) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool operates on the 'most recent email,' which is a key behavioral trait. However, it does not mention edge cases (e.g., no email, multiple emails, no codes found) or the return format. With no annotations, more detail would be expected for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the purpose and then provide usage guidance. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should hint at the return value. It mentions extracting 'OTP codes and verification links' but does not describe the format or behavior when no codes are found. This is a gap in completeness for a straightforward tool, though it is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'inbox_id' is fully described in the input schema as 'The inbox ID to extract codes from (uses most recent email).' The description adds usage context but no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract OTP codes and verification links from the most recent email in an inbox.' This is a specific verb+resource combination that distinguishes it from sibling tools like read_email or wait_for_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this after creating an inbox and receiving a verification/signup email,' providing clear context for when to use the tool. It does not list alternatives or exclusions, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get inbox details and list of received emails.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | The inbox ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read operation but does not explicitly state safety or side effects. Adequate for a simple retrieval, but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence captures tool's purpose without fluff. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), description adequately states what is returned. Lacks specifics on structure of inbox details or email list, but sufficient for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description 'The inbox ID'. Description adds no extra meaning beyond schema; baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get inbox details and list of received emails', using a specific verb and resource. It distinguishes from siblings like list_inboxes (lists all) and read_email (reads a single email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives; usage is implied by the name and purpose, but no guidance on when not to use or in comparison to read_email or wait_for_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active inboxes for the current API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source for behavioral traits. The description implies a read-only listing operation but does not disclose pagination, limit defaults, or error handling. Acknowledges scope (current API key) but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly sized for the task. No extraneous information; each word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no nested objects, the description is largely complete for a simple list operation. It could mention whether the result is all inboxes or paginated, but the context (current API key, active status) is sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the input schema (0 params, 100% coverage). Description adds no parameter info because none exist. Baseline for 0 params is 4, and the description correctly omits unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (active inboxes), and the scope (for the current API key). It effectively distinguishes from siblings like get_inbox (single inbox) and create_inbox (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., get_inbox). The description implies usage for listing all active inboxes, but lacks context for exclusions or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content of a specific email including body, headers, and attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| email_id | Yes | The email ID to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It fails to mention that reading is non-destructive, requires authentication, or what happens on missing email IDs. The statement is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and scope. It could be slightly more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should elaborate on return values (e.g., structure of body, headers, attachments) and error conditions. It does not, leaving important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, but the description adds no extra meaning beyond 'the email ID to read'. It does not explain format or origin of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads a specific email's full content including body, headers, and attachments. This distinguishes it from sibling tools like list_inboxes or create_inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, it does not clarify how read_email differs from get_inbox or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll an inbox until an email arrives. Returns the email once received. Times out after the specified duration.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes | The inbox ID to wait on | |
| timeout_seconds | No | Max seconds to wait (default: 60, max: 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions polling, returning email, and timeout, but does not disclose polling interval, whether email is marked as read, or any state changes. Acceptable for a simple wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the action. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description states return value ('the email'). For a low-complexity polling tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description repeats the timeout default/max already in schema, adding no new semantic value beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Poll', 'Returns') and resource ('inbox', 'email'), clearly distinguishing from siblings like 'get_inbox' (which likely returns inbox status) and 'read_email' (which reads a specific email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use ('Poll an inbox until an email arrives'), but does not explicitly mention when not to use or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2create_inboxdelete_inboxextract_codesget_inboxlist_inboxesread_emailwait_for_emailEach tool has a distinct, well-defined purpose with no overlap: create/delete/list/get inboxes, read specific emails, extract codes from emails, and wait for emails. The descriptions clearly differentiate their functions, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_inbox, extract_codes, wait_for_email). This predictability enhances usability and reduces confusion when scanning the toolset.
With 7 tools, the set is well-scoped for email inbox management, covering essential operations like inbox lifecycle, email retrieval, and code extraction. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.
The toolset provides complete coverage for disposable email workflows: CRUD operations for inboxes (create, delete, list, get), email handling (read, wait for), and utility functions (extract codes). No obvious gaps exist, enabling agents to perform end-to-end tasks without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Real email inboxes for AI agents: create inboxes, catch verification codes, extract OTPs, reply.
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Disposable inboxes for AI agents: create, wait for delivery, and extract email content or links.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/blipemail/blip'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
