MCP server for the Guerrilla Mail temporary email API.
Guerrilla Mail MCP has clear, action-verb naming and visible input schemas for all 6 tools. However, descriptions are minimal (10-60 chars, well below the 194-char baseline), parameter descriptions lack detail, and output schemas are not documented. No error recovery guidance, no parameter constraints (enums, ranges), and no indication of which operations are idempotent or destructive in the descriptions themselves. The code shows proper schema registration and basic error handling via try-catch, but lacks LLM-optimized guidance for tool selection and recovery.
Check the inbox. Pass seq to poll only emails newer than that id.
Delete one or more emails by id.
Fetch the full body of a single email by id.
Forget the current session and clear local session state.
Get a new disposable Guerrilla Mail address and start a session.
Set the local part of the email address for the current session.
Descriptions are 10 - 60 characters, far below the 194-char baseline. LLMs cannot determine when to select a tool vs. similar alternatives. E.g., 'Get a new disposable Guerrilla Mail address and start a session' lacks context on prerequisites, return value structure, or when to call it.
No parameter descriptions for 'lang' (get_email_address) and 'seq' (check_inbox). LLMs cannot infer valid values or formats. E.g., what language codes are accepted? Is seq a timestamp, sequence number, or email ID?
Output schemas are not documented. LLMs do not know what fields to expect from responses (e.g., does check_inbox return pagination info? Does fetch_email include attachments?). This forces agents to guess and risks parsing failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
No error recovery guidance. The fail() function returns raw error messages without actionable next steps. E.g., 'email_user is required' does not tell the LLM what to do, should it retry with a default, ask the user, or call a different tool?
Destructive operations (delete_emails, forget_me) lack confirmation or dry-run support. An agent could accidentally delete all emails without a safety gate. No idempotency guarantees documented.