fmsg-mcp

Reply in fmsg thread

reply

Destructive

Send an immediate threaded response to a message, choosing recipients and adding files or attachments. Messages are immutable, so nothing can be edited or recalled after sending.

Instructions

Send an immediate reply to a message (linking it into that thread). fmsg messages are immutable: once sent they cannot be edited or recalled. Send within the user's requested task or authorized automation. By default the reply goes to everyone on the parent message — its sender, recipients and anyone added later — except you; pass recipients to narrow or widen that. If you were added to the message after it was sent, you can reply to it but not to earlier messages in its thread. Fails if the parent is terminal (no replies possible); a parent marked no-reply is refused unless allow_no_reply is true. Secrets are redacted. Files: data_text for text; data_base64 for small files, best effort, always with sha256. Send files as they are; fmsg compresses them.

Input Schema

Name	Required	Description	Default
`id`	Yes	message to reply to
`body`	Yes	reply body; Markdown unless type says otherwise
`type`	No	body media type	text/markdown; charset=utf-8
`files`	No	files the user shared in this chat (images, PDFs and so on); the host fills these in and this server downloads them, so never write their bytes as base64
`no_reply`	No	ask recipients (and their agents) not to reply
`important`	No	mark as important for recipients
`recipients`	No	override the reply-all recipient set
`attachments`	No	files
`include_owner`	No	also send to your owner, if whoami shows one
`allow_no_reply`	No	reply even though the parent asked for no replies

Output Schema

Name	Required	Description
`id`	Yes
`to`	Yes
`from`	Yes
`hint`	No	for you, not the user: a better way to do this next time
`time`	Yes
`files`	No	the files given by reference, as attached: the name used, size and hex sha256 of the bytes
`topic`	Yes
`redacted`	No	the kinds of secret replaced, such as github_token; empty when none
`resolved`	No	short names and how they resolved, when any were given; confirm with the user if an address looks wrong
`warnings`	Yes	things to tell the user, such as redacted secrets or resolved short names
`parent_id`	Yes
`redactions`	Yes	secrets replaced with placeholders before sending
`attachments`	Yes	sorted by filename, the same order in every tool
`thread_topic`	No	the thread's topic: the topic sent for a new message; for a reply, the thread root's topic, or null when the root is not visible

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / files

Added value: +{
+  "description": "files the user shared in this chat (images, PDFs and so on); the host fills these in and this server downloads them, so never write their bytes as base64",
+  "items": {
+    "description": "a file the user shared in this chat, filled in by the host",
+    "properties": {
+      "download_url": {
+        "description": "filled in by the host",
+        "type": "string"
+      },
+      "file_id": {
+        "description": "filled in by the host",
+        "type": "string"
+      },
+      "file_name": {
+        "description": "filled in by the host",
+        "type": "string"
+      },
+      "mime_type": {
+        "description": "filled in by the host",
+        "type": "string"
+      }
+    },
+    "required": [
+      "download_url",
+      "file_id"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / files

Added value: +{
+  "description": "the files given by reference, as attached: the name used, size and hex sha256 of the bytes",
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "file_id": {
+        "type": "string"
+      },
+      "filename": {
+        "type": "string"
+      },
+      "sha256": {
+        "type": "string"
+      },
+      "size": {
+        "type": "number"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedv1.3.0Oct 22, 2026

changedInput schema / properties / attachments / items / properties / data_base64 / description

Previous value: -"base64 file contents, for small files. The host sets the size limit"New value: +"base64 file contents. You write the base64, so it is best effort: fine for small files (checked exact up to 16 KB). Always give sha256 with it. The host sets the size limit"

changedInput schema / properties / attachments / items / properties / sha256 / description

Previous value: -"hex sha256 of the file; the attachment is refused, and nothing sent, if the bytes differ. Give it when you can compute it"New value: +"hex sha256 of the file; the attachment is refused, and nothing sent, if the bytes differ. Always give it with data_base64"

Changed1 schema field changedv1.2.0Oct 17, 2026

addedInput schema / properties / include_owner

Added value: +{
+  "default": true,
+  "description": "also send to your owner, if whoami shows one",
+  "type": "boolean"
+}

Changed23 schema fields changedv1.1.0Oct 15, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / attachments / description
```
Added value: +"files"
```
addedInput schema / properties / attachments / items / additionalProperties
```
Added value: +false
```
addedInput schema / properties / attachments / items / properties / content_type / description
```
Added value: +"inferred from the filename when omitted"
```
addedInput schema / properties / attachments / items / properties / data_base64 / description
```
Added value: +"base64 file contents, for small files. The host sets the size limit"
```
removedInput schema / properties / attachments / items / properties / data_base64 / minLength
```
Removed value: -1
```

addedInput schema / properties / attachments / items / properties / data_text

Added value: +{
+  "description": "text file contents, sent as UTF-8 bytes; use instead of data_base64 for text",
+  "type": "string"
+}

addedInput schema / properties / attachments / items / properties / filename / description
```
Added value: +"file name"
```

addedInput schema / properties / attachments / items / properties / sha256

Added value: +{
+  "description": "hex sha256 of the file; the attachment is refused, and nothing sent, if the bytes differ. Give it when you can compute it",
+  "pattern": "^[0-9A-Fa-f]{64}$",
+  "type": "string"
+}

changedInput schema / properties / attachments / items / required

Previous value: -[
-  "filename",
-  "data_base64"
-]New value: +[
+  "filename"
+]

addedInput schema / properties / body / description

Added value: +"reply body; Markdown unless type says otherwise"

addedInput schema / properties / important / description
```
Added value: +"mark as important for recipients"
```

addedInput schema / properties / no_reply / description

Added value: +"ask recipients (and their agents) not to reply"

addedInput schema / properties / type / description
```
Added value: +"body media type"
```
changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +{}
```

addedOutput schema / properties / attachments / description

Added value: +"sorted by filename, the same order in every tool"

changedOutput schema / properties / attachments / items / additionalProperties
```
Previous value: -falseNew value: +{}
```

addedOutput schema / properties / attachments / items / properties / type

Added value: +{
+  "description": "media type; inferred from the filename when the host records none",
+  "type": "string"
+}

addedOutput schema / properties / hint

Added value: +{
+  "description": "for you, not the user: a better way to do this next time",
+  "type": "string"
+}

addedOutput schema / properties / redacted

Added value: +{
+  "description": "the kinds of secret replaced, such as github_token; empty when none",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / resolved

Added value: +{
+  "description": "short names and how they resolved, when any were given; confirm with the user if an address looks wrong",
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "address": {
+        "type": "string"
+      },
+      "input": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / thread_topic

Added value: +{
+  "description": "the thread's topic: the topic sent for a new message; for a reply, the thread root's topic, or null when the root is not visible",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / warnings / description

Added value: +"things to tell the user, such as redacted secrets or resolved short names"

First observedv0.1.3Sep 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With destructiveHint=true already declared, the description still adds substantial context: messages are immutable and cannot be edited or recalled, secrets are redacted, replies fail on terminal parents, no-reply parents are refused unless overridden, and late-added participants cannot reach earlier thread messages. These are non-obvious behavioral constraints an agent cannot get from annotations.

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?

Front-loaded with the action and threading effect, then audience defaults, then failure modes, then file handling. Sentences are dense but each carries distinct, call-relevant information with 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?

For a 10-parameter mutating tool with an output schema, this covers the critical uncertainties: delivery audience, immutability, refusal conditions, redaction, and attachment encoding. Minor gaps remain (it does not discuss important/no_reply effects or rate/ownership behavior for include_owner), but nothing essential to a correct call is missing.

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%, so baseline is 3; the description earns above that by explaining the recipients default/override semantics, the allow_no_reply escape hatch, and the data_text vs data_base64 + sha256 relationship for attachments. It leaves no_reply, important and include_owner to the schema, so it is not fully comprehensive.

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?

"Send an immediate reply to a message (linking it into that thread)" gives a specific verb (send), resource (reply to a message) and the key effect (thread linkage). "Immediate" implicitly separates it from create_draft/send_draft, though no sibling is named explicitly, so it falls just short of full sibling differentiation.

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?

It scopes usage ("Send within the user's requested task or authorized automation") and explains the default reply-all audience plus how recipients overrides it. It also states failure conditions (terminal parent, no-reply parent unless allow_no_reply) but never names an alternative tool such as create_draft or send_message for cases where a reply is wrong.

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

Deploy Server