Skip to main content
Glama

get_message

Retrieve a specific email message by ID, with optional body content and raw Graph payload for detailed inspection.

Instructions

Fetch a single message by id.

Args: message_id: Graph message id. mailbox: Optional mailbox. include_body: When True, the full body is returned. Default False (snippet only). include_raw: Include the raw Graph payload under "raw".

Returns: Trimmed message object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mailboxNo
message_idYes
include_rawNo
include_bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses meaningful behavior: include_body=False returns a snippet, include_body=True returns full body, include_raw embeds the raw Graph payload under 'raw', and the result is a trimmed message object. It stops short of describing error behavior or what 'trimmed' means exactly.

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

Conciseness5/5

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

A one-line summary followed by a compact Args/Returns block. Each line adds information and no filler is present, and the parameter documentation is easy to scan against the schema.

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

Completeness4/5

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

For a simple get-by-id tool with 4 params and no output schema, the description covers the purpose, all parameters, and the return concept. The main gap is that 'trimmed message object' is vague without an output schema, and mailbox's purpose is not explained beyond 'Optional mailbox'.

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

Parameters5/5

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

Schema description coverage is 0%, but the Args section gives each parameter real meaning: message_id is the Graph message id, mailbox is optional, include_body toggles snippet vs full body with default, and include_raw controls raw payload inclusion. This fully compensates for the bare schema.

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

Purpose5/5

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

Opens with 'Fetch a single message by id' – a specific verb, resource, and identity-based scope. This clearly distinguishes get_message from list_messages/search_messages, which are also in the sibling list.

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?

The description implies the right use case (you have a message_id and need one message), but it never says when to prefer this over list_messages/search_messages or sibling batch operations. No exclusions or alternative routing are provided beyond 'by id'.

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