fmsg-mcp

Reply in fmsg thread

reply

Destructive

Send an immediate response to a message, linking it into its thread, with optional recipients and attachments; fails if the parent cannot accept one.

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. 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; add sha256 when you can. Send files as they are; fmsg compresses them.

Input Schema

TableJSON 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
`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
`allow_no_reply`	No	reply even though the parent asked for no replies

Output Schema

TableJSON 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
`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.

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.6/5.0

Behavior5/5

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

Beyond the write/non-idempotent/destructive annotations, it discloses that messages are immutable and cannot be edited or recalled, the default recipient set ('everyone on the parent … except you'), the failure modes for terminal and no-reply parents, secret redaction, and attachment handling (sha256 refusal, server-side compression). This is genuinely additive behavioral context.

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?

Purpose is front-loaded and every sentence carries operational information — behavior, recipients, failure modes, secrets, attachments. It is dense with semicolon-joined clauses and a separate File guidance sentence, which reads slightly packed rather than wasteful.

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?

With an output schema present, return values need no explanation, and the description covers the remaining agent-critical concerns: recipient defaults, refusal/failure conditions, immutability, redaction, and attachment constraints. An agent has everything needed to call this correctly.

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 already 100%, so the baseline is 3. The description still adds meaning the schema does not: how recipients narrows or widens the reply-all default, when allow_no_reply applies, and when to supply sha256 or choose data_text over data_base64.

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 states a specific verb and resource ('Send an immediate reply to a message') and immediately clarifies the defining behavior — it is 'linking it into that thread' — which separates it from the plain send_message sibling. The 'immediate' qualifier also implicitly distinguishes it from the draft-based path (create_draft/send_draft).

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 gives clear operating context ('send within the user's requested task or authorized automation') and explicit when-not conditions: fails when the parent is terminal, and is refused for no-reply parents unless allow_no_reply is set. It does not name an alternative tool (e.g. send_message for a fresh thread), so it stops short of a full when/when-not/alternative map.

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

Deploy Server