Get the raw RFC822 bytes of one email message from a mailbox by providing the UID and mailbox address, enabling direct access to the complete message source.
Fetch one message's raw RFC822 bytes from a mailbox. Same app password auth as the list. Requires a management session token.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Path parameter `uid`. | |
| address | Yes | Query parameter `address`. |
Changes observed during successful MCP inspections.
v0.20.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=truecars, and the description adds the output format ('raw RFC822 bytes') plus an auth prerequisite ('management session token'), which is beyond the annotation. No contradiction with readOnlyHint.
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?
Three short sentences, front-loaded with the core purpose. Minor deduction for the vague reference 'as the list,' which requires the agent to infer which sibling tool is meant.
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 read-only single-message fetch, the description covers the output format (raw RFC822 bytes) and the critical auth prerequisite (management session token). It does not explain the address parameter's role beyond the schema, but the operation is simple enough that nothing critical is missing.
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% but the schema descriptions are tautological ('Path parameter uid'). The description adds mild context by clarifying the message and mailbox, but does not explain uid semantics or address format beyond that. Baseline 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 begins with a specific verb and resource: 'Fetch one message's raw RFC822 bytes from a mailbox.' This clearly identifies the tool's exact function and distinguishes it from siblings like mailkite_get_message by emphasizing raw bytes.
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 notes 'Same app password auth as the list' and 'Requires a management session token,' giving some operational context. However, it does not explicitly state when to prefer this tool over alternatives (e.g., get_message for parsed output), leaving the selection logic implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.