Read plain text for 1-10 exact email identities with ordered partial results, so you can inspect specific IMAP messages without sending, deleting, or moving them.
Read plain text for 1-10 exact identities with ordered partial results.
| Name | Required | Description | Default |
|---|---|---|---|
| identities | Yes | ||
| max_text_chars | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.10.0Output schema / $defs / AttachmentMetadataOutput / properties / encoded_sizeAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Encoded Size"
+}Output schema / $defs / AttachmentMetadataOutput / properties / size / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / $defs / AttachmentMetadataOutput / properties / size / typeRemoved value: -"integer"Output schema / $defs / AttachmentMetadataOutput / requiredPrevious value: -[
- "attachment_id",
- "filename",
- "content_type",
- "size"
-]New value: +[
+ "attachment_id",
+ "filename",
+ "content_type",
+ "size",
+ "encoded_size"
+]v0.9.0Input schema / properties / max_text_charsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Text Chars"
+}Output schema / $defs / MessageOutput / properties / text_total_charsAdded value: +{
+ "title": "Text Total Chars",
+ "type": "integer"
+}Output schema / $defs / MessageOutput / properties / text_truncatedAdded value: +{
+ "title": "Text Truncated",
+ "type": "boolean"
+}Output schema / $defs / MessageOutput / requiredPrevious value: -[
- "identity",
- "headers",
- "text",
- "flags",
- "attachments"
-]New value: +[
+ "identity",
+ "headers",
+ "text",
+ "flags",
+ "attachments",
+ "text_total_chars",
+ "text_truncated"
+]v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, non-destructive, closed-world, so the safety profile is covered. The description adds 'ordered partial results', which is genuinely beyond the annotations, but it is left vague – it never explains what causes partiality or what the ordering is keyed on.
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?
A single front-loaded sentence with no filler; the scope (plain text), the count bound (1-10), and the ordering/partiality note all earn their 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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with two parameters at 0% schema coverage, the description leaves the input contract (identity shape, text truncation) unexplained, which is a real gap for a batch read tool.
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 0% and the description adds no parameter meaning at all. The required 'identities' array of nested objects (account_id, mailbox, uid_validity, uid) and the optional max_text_chars are both undocumented, and the description does not compensate – it never says how an identity is expressed or what max_text_chars truncates.
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?
States a specific verb (Read) and resource (plain text of emails) scoped to '1-10 exact identities', which implicitly distinguishes it from get_email_html (HTML) and search_emails (search rather than exact lookup). It does not name a sibling explicitly, so it falls just short of a 5.
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?
'exact identities' and '1-10' imply the context of use (batch fetch when you already hold precise message references), but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative such as get_email for single messages or get_email_html for HTML bodies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.