Skip to main content
Glama

get_thread

Read-only

Fetch a thread by ID to read its content: plaintext and HTML bodies, headers, attachment metadata, and SPF/DKIM/DMARC authentication results. Use full:false when only headers and labels are needed.

Instructions

Fetch a thread by ID: headers, plaintext + HTML bodies, and attachment metadata. full defaults to true and should stay true whenever content matters. full: false is a headers-and-labels fetch for when a thread is too large to read or only its metadata is of interest — it does NOT fetch bodies or attachment metadata, and the result then omits plaintextBody, htmlBody and attachments entirely and sets metadataOnly: true. The fields are omitted rather than empty on purpose: an empty attachment list from a request that never looked is indistinguishable from a message that truly has none, and treating it as 'no attachment' has already nearly caused an invoice to be archived as attachment-less. If search reported hasAttachments: true, or the sender matters, use full: true. EVERY MESSAGE CARRIES authentication — SPF/DKIM/DMARC as the RECEIVING server reported them, for answering 'is this mail really from who it says?'. Read dmarc first: it is the only one of the three that ties a passing check to the visible From domain, so spf: pass alone proves nothing about the sender the user sees (a lookalike domain gets that trivially). signedBy/mailedBy/headerFrom name the domains each check actually validated. They do NOT have to match each other or the From address, and a mismatch is not by itself suspicious: a forwarded message legitimately shows the forwarder in mailedBy (the envelope sender is rewritten in transit) and in signedBy (the forwarder signs with its own key), while only headerFrom still names the original sender — which is exactly why dmarc is the result that carries meaning. Read those three as the explanation of a result, not as a test of their own. authservId says WHO asserts all this: a message can carry forged Authentication-Results headers of its own, and only the receiving server's report (for Gmail, mx.google.com) counts; otherReports counts further reports that were NOT read, and alsoReported lists results that disagree with the ones above. unchecked: true means the message carried no report at all — that is 'nobody looked', NOT 'nothing wrong'; unauthenticated does not imply forged, and authenticated does not imply honest (a phisher can hold a passing DMARC on his own lookalike domain). USE WHEN: reading a thread's content after finding it via search. DO NOT USE: with a message ID — this takes thread IDs. SIDE EFFECTS: none (does not mark as read).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
threadIdYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messagesYes
threadIdYes
metadataOnlyNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv0.17.0
    • addedOutput schema / properties / messages / items / properties / authentication
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "alsoReported": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "authservId": {
      +      "type": "string"
      +    },
      +    "dkim": {
      +      "type": "string"
      +    },
      +    "dmarc": {
      +      "type": "string"
      +    },
      +    "headerFrom": {
      +      "type": "string"
      +    },
      +    "mailedBy": {
      +      "type": "string"
      +    },
      +    "otherReports": {
      +      "type": "integer"
      +    },
      +    "returnPath": {
      +      "type": "string"
      +    },
      +    "signedBy": {
      +      "type": "string"
      +    },
      +    "spf": {
      +      "type": "string"
      +    },
      +    "unchecked": {
      +      "const": true,
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedOutput schema / properties / messages / items / required
      Previous value: -[
      -  "id",
      -  "threadId",
      -  "labelIds",
      -  "from",
      -  "to",
      -  "subject",
      -  "date",
      -  "snippet"
      -]New value: +[
      +  "id",
      +  "threadId",
      +  "labelIds",
      +  "from",
      +  "to",
      +  "subject",
      +  "date",
      +  "snippet",
      +  "authentication"
      +]
  2. Changed2 schema fields changedv0.15.1
    • changedOutput schema / properties / messages / items / required
      Previous value: -[
      -  "id",
      -  "threadId",
      -  "labelIds",
      -  "from",
      -  "to",
      -  "subject",
      -  "date",
      -  "snippet",
      -  "plaintextBody",
      -  "htmlBody",
      -  "attachments"
      -]New value: +[
      +  "id",
      +  "threadId",
      +  "labelIds",
      +  "from",
      +  "to",
      +  "subject",
      +  "date",
      +  "snippet"
      +]
    • addedOutput schema / properties / metadataOnly
      Added value: +{
      +  "const": true,
      +  "type": "boolean"
      +}
  3. First observedv0.1.8

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare `readOnlyHint: true`, and the description reinforces this with 'SIDE EFFECTS: none (does not mark as read).' It goes well beyond annotations by disclosing that `full: false` omits fields entirely and sets `metadataOnly: true`, explaining the rationale for omission rather than empty lists. It also warns about authentication-header forgery and how to interpret `authservId`, which is valuable behavioral context for downstream decisions.

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?

The description is front-loaded and well structured, with the core purpose in the first sentence and clear USE WHEN / DO NOT USE / SIDE EFFECTS sections. It is verbose, especially the detailed authentication-fields discussion, which goes beyond what is strictly needed for tool selection and invocation. Still, the extra detail is purposeful and organized rather than redundant.

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

Completeness5/5

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

Given the output schema exists and the two-parameter input schema is minimal, the description is thorough: it covers both parameters, side effects, use cases, exclusions, and even edge-case semantics like omitted fields and authentication-result interpretation. An agent has everything needed to call this tool correctly and interpret the result safely.

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%, so the description carries full parameter-semantics responsibility. It thoroughly explains `full` semantics, including defaults, behavior differences, omitted fields, and when to set it. For `threadId`, it clarifies that this tool expects thread IDs and not message IDs. Both parameters are meaningfully documented beyond 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?

The first sentence states a specific verb and resource: 'Fetch a thread by ID: headers, plaintext + HTML bodies, and attachment metadata.' It also distinguishes this from message-level or search tools with 'DO NOT USE: with a message ID — this takes thread IDs.' The purpose is unmistakable and well differentiated from siblings.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: 'USE WHEN: reading a thread's content after finding it via search' and 'DO NOT USE: with a message ID.' It also provides clear conditions for when to use `full: true` vs `full: false`, including the case where search reported `hasAttachments: true`. This is exactly the kind of actionable selection guidance an agent needs.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/csitte/mailwarden'

If you have feedback or need assistance with the MCP directory API, please join our Discord server