fmsg-mcp

Check fmsg delivery

delivery_status

Read-onlyIdempotent

Retrieve per-recipient delivery state for a message by ID, including delivered times, response codes, pending recipients, and retried temporary failures.

Instructions

Per-recipient delivery state of a message, including recipients added later. For a message you sent it is the delivery to each recipient; for a received message your host knows only its own receipt. Each entry has the delivered time and, when recorded, the receiving host's fmsg response code (200 accepted; others, such as 100 user unknown, are rejections). Delivery is asynchronous: pending recipients may still be delivered, and temporary failures are retried.

Input Schema

Name	Required	Description	Default
`id`	Yes	fmsg message id

Output Schema

Name	Required	Description	Default
`id`	Yes
`sent_at`	Yes
`recipients`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.1.0Oct 15, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +{}
```
changedOutput schema / properties / recipients / items / additionalProperties
```
Previous value: -falseNew value: +{}
```

addedOutput schema / properties / recipients / items / properties / code / description

Added value: +"the receiving host's fmsg response code for the last attempt when recorded: 200 means accepted, other codes are rejections; null when not recorded, including some successful deliveries"

addedOutput schema / properties / recipients / items / properties / code_meaning

Added value: +{
+  "description": "the code's name in the fmsg specification, when known",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / recipients / items / properties / status / description

Added value: +"one of \"delivered\", \"pending\", \"failed\"; delivered once the receiving host accepted it; failed when the last attempt was rejected (the host may retry temporary failures); otherwise pending. More values may be added"

removedOutput schema / properties / recipients / items / properties / status / enum
```
Removed value: -[
-  "delivered",
-  "pending",
-  "failed"
-]
```
addedOutput schema / properties / recipients / items / properties / time / description
```
Added value: +"when delivery was confirmed"
```

addedOutput schema / properties / recipients / items / properties / via / description

Added value: +"one of \"to\", \"add_to\"; how the recipient was addressed: to for the original recipients, add_to for recipients added later with the fmsg add-to mechanism (add_recipients). More values may be added"

removedOutput schema / properties / recipients / items / properties / via / enum
```
Removed value: -[
-  "to",
-  "add_to"
-]
```

First observedv0.1.3Sep 5, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavior beyond them: delivery is asynchronous, pending recipients may still succeed, temporary failures are retried, and recipients added later are included. It also decodes the response codes (200 accepted vs. 100 user unknown rejection), which is essential for interpreting output.

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?

Four sentences, front-loaded with the return meaning before the caveats. Every sentence contributes (scope, field meanings, async caveat), though the response-code parenthesis could be tightened.

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?

For a one-parameter read tool with annotations and an output schema, this is complete: it explains the sent/received distinction, per-entry fields, code semantics, and the async/retry model an agent needs in order to interpret a non-final status correctly.

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?

There is a single parameter with 100% schema description coverage ('fmsg message id'), so the schema carries the semantics. The description adds no format hints or constraints on the id beyond what the schema supplies, making the baseline of 3 appropriate.

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?

The opening clause, "Per-recipient delivery state of a message," states a specific resource and the grain of the result, and the sent-vs-received sentence clarifies the scope asymmetry. It does not name a sibling such as get_message to contrast with, so differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: you call it to check how a message's delivery is going. There is no explicit when-not or pointer to alternatives like get_message or list_sent, and no mention of what to do when an id is unknown.

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

Deploy Server