mcp-server-mattermost

update_message

Edit a posted Mattermost message by supplying its post ID and new text; original content is replaced and marked as edited. Add optional attachments for formatted updates.

Instructions

Edit an existing message.

Can only edit your own messages (unless admin). The message will show as edited. Original content is replaced; edit history is not preserved.

Attachment examples:

Status alert: {"color": "danger", "title": "Build Failed", "text": "Tests failed on main"}
With fields: {"title": "Ticket", "fields": [{"title": "Status", "value": "Open", "short": true}]}

Input Schema

TableJSON Schema

Name	Required	Description
`message`	Yes	New message content
`post_id`	Yes	26-character post/message 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.4/5.0

Behavior5/5

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

The description discloses key behavioral details: the message will be marked as edited, original content is replaced, and edit history is not preserved. These details go well beyond the single destructiveHint annotation and help an agent understand the side effects of mutation.

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 front-loaded with the core purpose, then adds only high-value behavioral caveats and concrete attachment examples. Every sentence earns its place and there is no filler.

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?

The description covers permissions, edit-visibility, replacement semantics, history behavior, and attachment formatting examples. It is complete enough for a mutation tool with an output schema, though it could have explicitly noted what happens to existing attachments when the attachments parameter is omitted.

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

Parameters3/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 3; the schema already documents message, post_id, and attachments thoroughly. The attachment examples add practical formatting guidance, but they show bare attachment objects rather than the array shape the schema expects, which slightly weakens their value.

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 opening phrase 'Edit an existing message' names a specific verb and resource, and clearly distinguishes this tool from sibling post_message and delete_message. It states what the operation does without ambiguity.

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 gives relevant usage context by stating that only the user's own messages can be edited unless the user is admin. It does not explicitly contrast with sibling tools like post_message or delete_message, but the edit-vs-create/edit-vs-delete distinction is strongly implied.

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