mcp-server-mattermost

post_message

Send messages to Mattermost channels with Markdown, thread replies, file attachments, and rich formatted alerts.

Instructions

Post a message to a Mattermost channel.

Send text messages with Markdown support. Use root_id to reply in a thread. Use file_ids to attach uploaded files. Use attachments for rich formatted content. To read all messages in a thread, use get_thread.

Attachment examples:

Status alert: {"color": "danger", "title": "Build Failed", "text": "Tests failed on main"}
Success notification: {"color": "good", "title": "Deployed", "text": "v1.2.3 is live"}
With fields: {"title": "Ticket", "fields": [{"title": "Status", "value": "Open", "short": true}]}

Input Schema

TableJSON Schema

Name	Required	Description
`message`	Yes	Message content (supports Markdown)
`root_id`	No	Root post ID for threading
`file_ids`	No	File IDs to attach (from upload_file)
`channel_id`	Yes	26-character channel identifier (e.g., 'o5w8h47pdfbzjc4d8w7dhnhren')
`attachments`	No	Rich message attachments with colors, fields, images

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Unique post identifier
`type`	Yes	Post type (empty for regular posts)
`edit_at`	Yes	Last edit timestamp
`message`	Yes	Post content (supports Markdown)
`root_id`	Yes	Root post ID if in thread
`user_id`	Yes	Author user identifier
`file_ids`	No	Attached file IDs
`hashtags`	Yes	Space-separated hashtags
`create_at`	Yes	Creation timestamp in milliseconds
`delete_at`	Yes	Deletion timestamp (0 if not deleted)
`is_pinned`	Yes	Whether post is pinned
`update_at`	Yes	Last update timestamp in milliseconds
`channel_id`	Yes	Channel where posted
`original_id`	Yes	Original post ID if edited
`pending_post_id`	Yes	Client-side pending ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.1Sep 10, 2026

changedOutput schema / required

Previous value: -[
-  "id",
-  "create_at",
-  "update_at",
-  "delete_at",
-  "edit_at",
-  "user_id",
-  "channel_id",
-  "root_id",
-  "original_id",
-  "message",
-  "type",
-  "hashtags",
-  "file_ids",
-  "pending_post_id",
-  "is_pinned"
-]New value: +[
+  "id",
+  "create_at",
+  "update_at",
+  "delete_at",
+  "edit_at",
+  "user_id",
+  "channel_id",
+  "root_id",
+  "original_id",
+  "message",
+  "type",
+  "hashtags",
+  "pending_post_id",
+  "is_pinned"
+]

First observedv0.5.1Jul 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description transparently discloses that this action posts/sends a message with Markdown support and attachment capabilities, going well beyond the sole destructiveHint=false annotation. It adds useful behavioral context about thread replies and rich attachments; it does not detail permissions or rate limits, but the behavior is clear for a messaging operation.

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?

The description is compact and front-loaded: it states the core action first, then maps each parameter to its use, then gives a cross-reference to get_thread. The attachment examples are focused and non-redundant, adding practical value instead of restating the schema.

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?

The description is complete for this tool's complexity: the schema covers parameter types, the output schema covers returns, and the description covers when to use the tool and provides advanced attachment examples. The explicit pointer to get_thread closes the main alternative-use question an agent might have.

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 100%, so the baseline is met by the schema. The description adds value beyond the schema by explaining the purpose of root_id, file_ids, and attachments, and by including concrete attachment JSON examples for common use cases. This meaningfully helps an agent construct params.

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 opens with a specific verb-resource pair: 'Post a message to a Mattermost channel.' It also distinguishes this from related read operations by pointing to get_thread for reading messages, and the overall message clearly differentiates 'post' from sibling tools like update_message and delete_message.

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

Usage Guidelines4/5

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

The description clearly says when to use root_id (reply in a thread), file_ids (attach uploaded files), attachments (rich content), and explicitly routes reading a thread to get_thread. It lacks an explicit 'when not to use this tool' statement, but the alternatives and usage modes are clear enough.

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