fmsg-mcp

Create fmsg draft

create_draft

Creates an unsent message or reply draft so you can compose, review, and discard it before sending; nothing is sent until the draft is sent.

Instructions

Create an unsent draft: a new message, or a reply when reply_to is given (reply rules and reply-all apply). Nothing is sent until send_draft; delete_draft discards it. The draft is visible in the user's other fmsg clients. Secrets in the body and topic are redacted.

Input Schema

Name	Required	Description	Default
`to`	No	recipient addresses (@user@domain) or short names; for a reply, overrides reply-all
`body`	Yes	message 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
`topic`	No	thread topic for a new message; not allowed with reply_to
`no_reply`	No	ask recipients (and their agents) not to reply
`reply_to`	No	message this draft replies to
`important`	No	mark as important for recipients
`attachments`	No	files to attach now
`include_owner`	No	also send to your owner, if whoami shows one
`allow_no_reply`	No	draft a reply even though the parent asked for no replies

Output Schema

Name	Required	Description
`to`	Yes
`hint`	No	for you, not the user: a better way to do this next time
`next`	Yes
`files`	No	the files given by reference, as attached: the name used, size and hex sha256 of the bytes
`topic`	Yes
`upload`	No	where to upload more attachments; present when this server has a public URL
`draft_id`	Yes
`redacted`	Yes	the kinds of secret replaced; 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 in the draft
`attachments`	Yes	sorted by filename, the same order in every tool

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

Addedv1.1.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The annotations already declare this as non-read-only, non-destructive, non-idempotent, and closed-world. The description adds useful behavioral context beyond those annotations: drafts are visible in the user's other fmsg clients, nothing is sent until send_draft, and secrets in body and topic are redacted. It does not cover auth requirements or rate limits, so a 4 is appropriate.

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 four short sentences with no wasted words. The key constraint, that the draft is unsent until send_draft, is front-loaded and easy to act on.

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?

Given 11 parameters, full schema coverage, an output schema, and annotations, the description covers the important behavioral context: draft lifecycle, visibility, redaction, and reply semantics. It leaves lower-level details such as attachments and recipient/owner flags to the schema, which is reasonable, though a brief note on host-filled files would make it fully complete.

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 the schema already documents all 11 parameters in detail. The description still adds meaning beyond the schema by clarifying reply behavior when reply_to is supplied, noting that reply rules and reply-all apply, and stating that secrets in body and topic are redacted. Those additions justify a 4 over the baseline 3.

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: creating an unsent draft as either a new message or a reply. It explicitly distinguishes the draft-creation step from sending and deleting via send_draft and delete_draft, so an agent can identify the tool without opening the schema.

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 clearly explains the lifecycle: nothing is sent until send_draft, and delete_draft discards the draft. It also explains that reply_to creates a reply and that reply rules and reply-all apply. It does not explicitly contrast itself with the sibling reply or send_message tools, which keeps it from a 5.

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

Deploy Server