Skip to main content
Glama
vanisoul
by vanisoul

mattermost_get_thread

Read-onlyIdempotent

Fetches the discussion thread and all replies for a given post ID so you can read the full conversation context. Read-only operation.

Instructions

取得指定訊息所屬的討論串及回覆。唯讀操作。

Input Schema

NameRequiredDescriptionDefault
postIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the sentence '唯讀操作' (read-only operation) merely restates the structured data and earns no credit. Nothing is added about reply ordering, pagination or limits on the number of replies returned, or what happens when the post has no replies. For a thread-fetch tool, that behavioral detail matters.

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?

Two short sentences, with the retrieval scope stated first and the safety note second. There is no filler. The only weakness is that brevity here comes at the cost of the usage and parameter detail noted above.

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

Completeness3/5

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

For a one-parameter read tool with no output schema, the description is minimally adequate: an agent can tell it returns a thread of replies. It omits what the returned thread contains, how replies are ordered, and how to choose this tool over mattermost_get_post, which leaves a real gap for correct tool selection.

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

Parameters2/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 explain the single parameter, yet it only says '指定訊息' (the specified message), which barely clarifies that postId is a post identifier. The 26-character lowercase alphanumeric format and the fact that the ID must be a post ID rather than a channel or user ID are left to the schema pattern and the agent's inference.

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 and resource: fetch the thread and its replies that belong to a given message ('取得指定訊息所屬的討論串及回覆'). This clearly separates it from mattermost_get_post, which returns a single post, and from mattermost_reply_to_thread, which writes. It does not explicitly name those siblings, so the description falls short of the sibling differentiation required for a 5.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool rather than mattermost_get_post (a single message), mattermost_search_posts, or mattermost_get_channel. The intended use, retrieving a whole thread when you hold a post ID, can only be inferred. Neither prerequisites nor exclusions are mentioned.

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