Skip to main content
Glama

fetch_topic

Retrieve every message tied to a specific topic tag in a project, regardless of recipient, to review topic threads and filter by recency or unread status.

Instructions

Fetch all messages in a project with a given topic tag, regardless of recipient.

Parameters

project_key : str Project identifier. topic_name : str The topic tag to filter by (case-insensitive). limit : int Max number of messages to return (default 50). include_bodies : bool Include full Markdown bodies in the payloads (default true). since_ts : Optional[str] ISO-8601 timestamp; only messages newer than this are returned. unread_only : bool When True, restrict to messages where the viewer has a recipient row that has not been explicitly marked read. This narrows beyond the default sender-or-recipient visibility — messages the viewer sent (but is not a recipient of) and broadcast/thread-visible messages where the viewer has no MessageRecipient row are excluded under this flag, because "unread" is only well-defined for a recipient row. A bare fetch_topic call does NOT mark messages read.

Returns

list[dict] Each message includes: { id, subject, from, created_ts, importance, topic, [body_md] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
formatNo
since_tsNo
agent_nameNo
topic_nameYes
project_keyYes
unread_onlyNo
include_bodiesNo
registration_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.4

TDQS

A4.2/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 burden and does disclose non-obvious behavior: a bare call does not mark messages read, and unread_only narrows visibility in a way that excludes sent and broadcast messages lacking a MessageRecipient row. It omits permissions/auth context that the unexplained registration_token and agent_name parameters imply, and says nothing about truncation when limit is hit.

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?

Numpydoc-style layout is front-loaded with the one-line purpose, then parameters and returns, so an agent can stop reading early. The longer unread_only paragraph earns its length by resolving a genuinely ambiguous flag.

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?

An output schema exists, yet the description still summarizes the returned fields, and it covers the two required parameters plus the main filters. The gap is the auth/identity parameters, which are neither in the schema nor explained, leaving an agent unsure whether credentials are needed for this call.

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 six of nine parameters with real semantics, including the delicate unread_only narrowing rule and the include_bodies payload effect. Three parameters (format, agent_name, registration_token) remain undocumented in both description and 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 (fetch), resource (messages), and a scoping rule (with a given topic tag, regardless of recipient) that immediately separates it from recipient-scoped siblings like fetch_inbox. An agent can distinguish it from fetch_inbox and search_messages 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 Guidelines3/5

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

The phrase 'regardless of recipient' implicitly contrasts with inbox-style retrieval, and the note that a bare call does not mark messages read hints at mark_message_read as the follow-up. However, no sibling is named explicitly and there is no stated when-not condition, leaving routing to inference.

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