himalaya-mcp

Overview Schema Source Related Servers Discussions Admin

render_email

Reads an email body as clean Markdown, converting HTML emails for easier reading and returning plain-text bodies unchanged.

Instructions

Read an email body rendered as clean markdown. For HTML emails, converts to markdown for a clean reading experience. For plain text emails, returns the body as-is.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "render_email"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Email message ID
`folder`	No	Folder name (default: INBOX)
`account`	No	Account name (uses default if omitted)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.2.2Nov 7, 2026

addedInput schema / properties / id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "maximum": 9007199254740991,
+    "minimum": 0,
+    "type": "integer"
+  }
+]

removedInput schema / properties / id / type
```
Removed value: -"string"
```

Addedv2.0.0Jul 25, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden. It does add genuine value by disclosing the HTML-to-markdown conversion and pass-through for plain text, but it omits whether the call is read-only by construction, what happens on an invalid ID or missing folder, and whether attachments or large bodies are truncated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the format-handling rule. The phrase 'for a clean reading experience' is mildly redundant with 'clean markdown', but nothing else wastes space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter read tool with no output schema, the description covers the essential transformation behavior. It is still thin on return contents (headers, subject, body-only?) and on error or fallback behavior, which an agent would want before choosing it over sibling readers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so id, folder, and account are already documented, and the description adds nothing beyond them. Baseline 3 applies since the schema does the heavy lifting for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read an email body') plus the output form ('rendered as clean markdown'), which is more precise than the name alone. It doesn't explicitly distinguish itself from close siblings like read_email, read_email_html, or read_email_raw, so an agent must infer the split from the format-handling sentences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the tool is evidently the markdown-normalized reader, and the HTML/plain-text sentences hint at why you would pick it over read_email_html. There is no explicit when-to-use or when-not-to-use statement, and no mention of read_email or read_email_raw as alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.