fmsg-mcp

Show fmsg identity

whoami

Read-onlyIdempotent

Report the fmsg address this server acts as, its owner if it is a sub-address, the fmsg Web API URL and how short names resolve, and this server's version and build. Call this first if unsure who you are sending as.

Instructions

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`owner`	No	owner of this sub-address, included as a recipient of messages you send unless include_owner is false; absent for an owner's own address
`address`	Yes
`api_url`	Yes
`transport`	Yes	one of "stdio", "http"; http is Streamable HTTP. More values may be added
`server_build`	No	git describe of the build, such as v1.2.3-4-g80e0418, when recorded
`server_commit`	No	the git commit this server was built from, when the build recorded it
`default_domain`	Yes
`server_version`	No	this fmsg-mcp server's release version
`directory_names`	Yes	short names in the operator-configured directory; empty when there are none
`token_expires_at`	Yes	internal: when the server's current upstream access token expires; it is renewed automatically, so no action is needed

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.3.0Oct 22, 2026

addedOutput schema / properties / server_build

Added value: +{
+  "description": "git describe of the build, such as v1.2.3-4-g80e0418, when recorded",
+  "type": "string"
+}

addedOutput schema / properties / server_commit

Added value: +{
+  "description": "the git commit this server was built from, when the build recorded it",
+  "type": "string"
+}

addedOutput schema / properties / server_version

Added value: +{
+  "description": "this fmsg-mcp server's release version",
+  "type": "string"
+}

Changed1 schema field changedv1.2.0Oct 17, 2026

addedOutput schema / properties / owner

Added value: +{
+  "description": "owner of this sub-address, included as a recipient of messages you send unless include_owner is false; absent for an owner's own address",
+  "type": "string"
+}

Changed5 schema fields changedv1.1.0Oct 15, 2026

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

addedOutput schema / properties / directory_names / description

Added value: +"short names in the operator-configured directory; empty when there are none"

addedOutput schema / properties / token_expires_at / description

Added value: +"internal: when the server's current upstream access token expires; it is renewed automatically, so no action is needed"

addedOutput schema / properties / transport / description

Added value: +"one of \"stdio\", \"http\"; http is Streamable HTTP. More values may be added"

removedOutput schema / properties / transport / enum
```
Removed value: -[
-  "stdio",
-  "http"
-]
```

Changed1 schema field changedv0.2.3Sep 25, 2026
- changedOutput schema / properties / api_url / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
First observedv0.1.3Sep 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds what the agent actually learns (identity, owner relationship, resolution rules, build info) and frames it as a safe diagnostic entry point, which is real context beyond the annotations.

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?

Two sentences, front-loaded with what is reported, then the routing hint. The enumerated return items are slightly long but each maps to a distinct piece of identity information; nothing is padding.

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?

An output schema exists, so the description needn't detail the return shape; annotations fully cover side effects; there are no parameters to explain. What remains — what identity facts are exposed and when to call it — is fully stated.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter guidance is given.

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?

States a specific verb ('Report') and a well-defined resource set: the acting fmsg address, sub-address owner, Web API URL, short-name resolution, and server version/build. It is unmistakably distinct from every sibling tool (send/reply/list/delete family), which are all message operations.

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?

Explicitly says 'Call this first if unsure who you are sending as,' giving a concrete trigger condition. It doesn't name a fallback alternative (e.g., resolve_address for address syntax questions), but the call-first guidance is actionable on its own.

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

Deploy Server