Skip to main content
Glama
cloud-ru-tech

mcp-server-mattermost

get_channel_messages

Read-onlyIdempotent

Retrieve recent channel messages, unread posts, or updates since a given timestamp. Supports pagination, unread-only mode, and sync from a watermark.

Instructions

Get messages from a channel — recent history, the user's unread window, or posts changed since a watermark.

Three mutually-exclusive modes. Pick by user intent:

  • "Show last N" / "what's in this channel" → default (page, per_page). Reverse-chronological. truncated=True ⇒ more posts exist; paginate.

  • "What did I miss" → unread_only=True. The user's unread window anchored at last_viewed_at, with limit_before context posts. Quirk: on a never-viewed channel (last_viewed_at == 0) order is empty even when unread_msg_count > 0 — call mark_channel_viewed once to bootstrap.

  • "Sync everything since " → since=<unix_ms>. Posts with update_at > since, including edits of older posts and tombstones (delete_at != 0, empty message). Server caps at 1000; on truncated=True step the watermark forward in smaller windows.

Returns {order, posts, truncated}. posts may contain more entries than order (root posts pulled in by thread replies). System posts (type starts with "system_") appear in unread_only/since responses but are NOT counted in unread_msg_count.

For keyword search use search_messages; for full threads use get_thread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (0-indexed)
sinceNoUnix timestamp in milliseconds (>= 10^12, i.e. >= 2001-01-01); return posts modified after this time. Mutually exclusive with unread_only and pagination. Use ChannelWithUnreads.last_viewed_at from list_my_channels.
per_pageNoResults per page
channel_idYes26-character channel identifier (e.g., 'o5w8h47pdfbzjc4d8w7dhnhren')
limit_afterNoIn unread_only mode: unread posts to return (1-200)
unread_onlyNoReturn only the user's unread window via /posts/unread
limit_beforeNoIn unread_only mode: read context posts before the first unread (max 200)
collapsed_threadsNoSet True only if the user has CRT (Collapsed Reply Threads) enabled. Team default is CRT off — leave False unless you know otherwise. Requires unread_only=True or since=<ms>; the default /posts endpoint rejects CRT-aware queries.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
orderYesPost IDs in display order
postsYesMap of post ID to Post object
truncatedNoTrue when the response hit a Mattermost response cap — more posts exist beyond this batch
next_post_idNoNext post ID for pagination
prev_post_idNoPrevious post ID for pagination
Behavior5/5

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

Annotations declare readOnlyHint and idempotentHint. The description adds extensive behavioral details: quirk about never-viewed channel, server cap at 1000 for since, truncated flag, system posts behavior, and that posts may contain more entries than order. No contradictions.

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 well-structured with clear sections for modes, but slightly long. Every sentence provides value, so it earns its length. Minor reduction for not being more concise.

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 tool's complexity (8 parameters, 3 modes, quirks), the description is thorough. Output schema exists, so return values need not be explained. Covers all necessary context for effective use.

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%, but the description adds meaning by explaining parameter interactions (mutual exclusivity of unread_only and since with pagination) and specific guidance for collapsed_threads. This goes beyond schema commentary.

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 description clearly states the tool retrieves messages from a channel and lists three mutually exclusive modes. It differentiates from sibling tools like search_messages and get_thread by specifying their purposes.

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?

Explicitly tells when to use each mode (default for recent history, unread_only for missed posts, since for syncing), and warns about CRT usage. Also directs to search_messages for keyword search and get_thread for full threads.

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

Install Server

Other Tools

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/cloud-ru-tech/mcp-server-mattermost'

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