Skip to main content
Glama
Sign In

DataToRAG

by com.datatorag
OverviewDiscussionsAdmin

gws-mcp__gmail_read

Read-only

Read a specific email message by its ID. By default returns the full message including headers, body, and metadata. Use text_only for a compact view (flattened headers, decoded text body, attachment metadata) that avoids large MIME/base64 payloads. Each attachment is listed with its part ID; gmail_get_attachment takes the message ID and that part ID and returns the attachment's text, or describes a file that is not text.

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": {
      "message_id": "<message_id>"
    },
    "name": "gws-mcp__gmail_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
text_onlyNoReturn a compact view instead of the raw MIME payload: flattened from/to/cc/subject/date headers, the decoded text/plain body (falls back to tag-stripped text/html), and attachment metadata (partId, filename, mimeType, attachmentId). Recommended for triage: it avoids base64 attachment data overflowing the response.
message_idYesThe Gmail message ID to read
max_body_charsNoTruncate the returned body text to this many characters (adds a truncation marker). Implies text_only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is settled; the description adds real behavioral context beyond that: the default returns full MIME including headers/body/metadata, while text_only avoids large MIME/base64 payloads. It also explains the follow-up contract with gmail_get_attachment. Response size/truncation mechanics are largely delegated to the schema, keeping this just short of a 5.

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?

Three sentences, front-loaded with the core action, then the default behavior, then the compact mode and attachment follow-up. Every sentence carries distinct information with no repetition of 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?

Complete enough for a read tool: default vs compact return shape is described, and the attachment handoff is explicit despite there being no output schema. Minor gaps remain around whether truncation applies in the default mode and any size limits, but nothing blocking for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining what the text_only mode actually returns (flattened headers, decoded text body, attachment metadata with part IDs) and how the attachment part ID links to the sibling tool. max_body_chars and account are left entirely to the 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?

States a specific verb and resource ('Read a specific email message by its ID') and distinguishes itself from siblings by naming the attachment-fetch tool and the compact mode. An agent can tell this apart from gmail_search, gmail_list, and gmail_get_attachment without opening any schema.

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

Usage Guidelines4/5

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

Gives clear guidance on choosing text_only for triage/compact viewing and routes attachment extraction to gmail_get_attachment with the required message and part IDs. It does not explicitly say you must first obtain the message_id from gmail_search or gmail_list, which is the main missing routing hint.

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

All DataToRAG toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources