fmsg-mcp

Send fmsg draft

send_draft

Destructive

Sends an existing draft and its attachments immediately to deliver authorized messages; if the host refuses, the reason is returned and the message stays a draft.

Instructions

Send a draft made with create_draft, with its attachments, immediately. fmsg messages are immutable: once sent they cannot be edited or recalled. Send within the user's requested task or authorized automation. If the host refuses it, its reason is returned verbatim and the message stays a draft.

Input Schema

Name	Required	Description	Default
`id`	Yes	the draft to send

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.

Changed1 schema field changedv1.5.1Nov 5, 2026

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"
+}

Addedv1.1.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the irreversible consequence of the write ("fmsg messages are immutable: once sent they cannot be edited or recalled"), which is far more actionable than destructiveHint=true alone. It also documents the failure path — the host's reason is returned verbatim and the message remains a draft — so the agent knows a refusal leaves state unchanged and is safely reportable.

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?

Four short sentences, front-loaded with the action, then the consequence, then the authorization boundary, then the failure mode. No filler and no restatement of the title.

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 destructive, non-idempotent, single-parameter tool with an output schema, the description covers prerequisite, side effect, refusal behavior, and authorization scope — enough to call it correctly. It does not state what happens to the draft record on success (consumed vs. retained), which is the one remaining ambiguity.

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 coverage is 100% and the single 'id' parameter is already documented as "the draft to send" with a numeric pattern, so the description adds little parameter-level detail. The only marginal addition is that the draft's attachments are included, which the schema does not express. Baseline 3 is appropriate.

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?

Names a specific verb and resource ("Send a draft") and anchors it to the producing sibling ("made with create_draft"), so an agent can distinguish it from send_message or reply without opening a schema. Adding "with its attachments" clarifies exactly what payload goes out.

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?

"Send within the user's requested task or authorized automation" gives a concrete authorization/scope condition for when sending is appropriate, and the create_draft reference establishes the prerequisite. It stops short of explicitly contrasting with send_message or reply, so the alternative-selection guidance is implied rather than stated.

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

Deploy Server