MCP Agent Mail

summarize_thread

Extract participants, key points, and action items from one or more message threads, producing a detailed summary or aggregate digest for agent coordination.

Instructions

Extract participants, key points, and action items for one or more threads.

Single-thread mode (thread_id is a single ID):

Returns detailed summary with optional example messages
Response: { thread_id, summary: {participants[], key_points[], action_items[]}, examples[] }

Multi-thread mode (thread_id is comma-separated IDs like "TKT-1,TKT-2,TKT-3"):

Returns aggregate digest across all threads
Response: { threads: [{thread_id, summary}], aggregate: {top_mentions[], key_points[], action_items[]} }

Parameters

project_key : str Project identifier. thread_id : str Single thread ID for detailed summary, OR comma-separated IDs for aggregate digest. include_examples : bool If true (single-thread mode only), include up to 3 sample messages. llm_mode : bool If true and LLM is enabled, refine the summary with AI. llm_model : Optional[str] Override model name for the LLM call. per_thread_limit : int Max messages to consider per thread (multi-thread mode).

Examples

Single thread:

{"thread_id": "TKT-123", "include_examples": true}

Multiple threads:

{"thread_id": "TKT-1,TKT-2,TKT-3"}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`format`	No
`llm_mode`	No
`llm_model`	No
`thread_id`	Yes
`agent_name`	No
`project_key`	Yes
`include_examples`	No
`per_thread_limit`	No
`registration_token`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.4Sep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses the exact response shapes per mode, that include_examples is single-thread only and caps at 3 samples, that llm_mode refines via AI only when enabled, and that per_thread_limit bounds multi-thread work. It omits any statement of read-only nature, auth/permission needs, or side effects.

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?

Front-loaded with the one-line purpose, then organized into modes, response shapes, parameters, and examples. It is longer than average, and the response-shape blocks and examples partially overlap, but the structure is scannable and each section adds value for a 9-param tool.

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 complex, unannotated tool with 9 params, the description covers modes, most parameters, and request examples. An output schema exists so return values need not be restated, but the three undocumented parameters represent a genuine completeness gap.

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 description coverage is 0%, so the description must compensate, and it documents 6 of 9 parameters (project_key, thread_id, include_examples, llm_mode, llm_model, per_thread_limit) with real semantic meaning plus usage examples. It leaves format, agent_name, and registration_token entirely undocumented.

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 (extract) and resource set (participants, key points, action items) over one or more threads, and clearly separates single-thread from multi-thread behavior. The purpose is unmistakable, though it never names or differentiates itself from siblings like summarize_recent or fetch_summary.

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?

It clearly explains the two operating modes and how thread_id format selects between them, which implies usage. However, it gives no guidance on when to choose this tool over alternatives such as summarize_recent or fetch_summary, and states no exclusions or prerequisites.

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