fmrl

Check this machine's fmrl key and account

fmrl_whoami

Idempotent

Show this machine's fmrl key and account, monthly publish usage and reset, key-ring sync, and plugin status. Use it to check the agent's identity, publish quota, or private page sync.

Instructions

Show this machine's fmrl key: its prefix and name, this month's free publishes used and when they reset, whether the agent is attached to a person's fmrl account and where its canvases show, where the key ring is kept, and whether the installed plugin is current. Use it when the person asks which fmrl key or account the agent uses, how many publishes are left, or whether private page keys are synced. For fmrl-mcp's version and connection health use fmrl_status, and to attach the agent use fmrl_attach. It makes a key on first use when this machine has none and gives an unnamed key this app's name; when the account has private page sync on, it syncs this machine's key ring to it. A revoked key is reported, not replaced.

Input Schema

Name	Required	Description	Default
`trust_vault`	No	Only after this tool said the account's vault fingerprint changed: the new fingerprint, exactly as fmrl.site/account shows it, once the person confirms they reset private page sync there. Trusting it lets this machine's key rings sync to that vault again. Leave out otherwise.

Output Schema

Name	Required	Description
`ring`	No
`label`	No	The key's name, which the revisions it makes carry. Absent while unnamed.
`notes`	No
`quota`	Yes	This month's free publishes: how many are used, the monthly limit, and when the count resets.
`plugin`	No
`prefix`	Yes	The key's public prefix, the part safe to show; the secret is never returned.
`canvases`	No	The sentence whoami's text says about where this agent's canvases show on fmrl.site, word for word.
`link_url`	No
`linked_at`	No
`attach_url`	No	A one-time link that attaches an unattached agent, when one was supplied. Relay it unchanged.
`created_at`	Yes
`rotated_at`	No	When the key's secret was last rotated.
`attached_at`	No	When the agent was attached to a person's fmrl account; null while unattached.
`attached_via`	No	Where an attached agent's canvases show: account, in every browser signed in to its person's fmrl account; browser, only in the one browser it was attached from. Absent while unattached or when the server does not say.
`canvases_url`	No	The fmrl.site page that opens its person's canvases, where an attached agent's canvases are listed tagged with this key's prefix.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.17.8Nov 9, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / trust_vault / description

Added value: +"Only after this tool said the account's vault fingerprint changed: the new fingerprint, exactly as fmrl.site/account shows it, once the person confirms they reset private page sync there. Trusting it lets this machine's key rings sync to that vault again. Leave out otherwise."

addedOutput schema / properties / attach_url / description

Added value: +"A one-time link that attaches an unattached agent, when one was supplied. Relay it unchanged."

addedOutput schema / properties / attached_at / description

Added value: +"When the agent was attached to a person's fmrl account; null while unattached."

addedOutput schema / properties / label / description

Added value: +"The key's name, which the revisions it makes carry. Absent while unnamed."

addedOutput schema / properties / prefix / description

Added value: +"The key's public prefix, the part safe to show; the secret is never returned."

addedOutput schema / properties / quota / description

Added value: +"This month's free publishes: how many are used, the monthly limit, and when the count resets."

addedOutput schema / properties / rotated_at / description

Added value: +"When the key's secret was last rotated."

First observedv0.17.6Nov 9, 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=false, idempotentHint=true and destructiveHint=false, and the description goes beyond them by disclosing the actual write side effects: it mints a key on first use, names an unnamed key after the app, and syncs this machine's key ring when private page sync is on. It also states a failure posture ('A revoked key is reported, not replaced'), which is real behavioral context. The only minor gap is that it does not say how the sync interacts with a changed vault fingerprint, which is left entirely to the trust_vault parameter description.

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?

It is front-loaded with what the tool reports, then usage triggers, then alternatives, then side effects – a sensible ordering with no filler sentences. The opening enumeration is dense and long, but every clause maps to a distinct piece of returned information.

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 tool with real side effects and an output schema, the description covers purpose, triggers, alternatives, mutation behavior, and failure handling, while return values are correctly left to the output schema and trust_vault to the parameter schema. Nothing an agent needs in order to call this correctly is missing.

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 description coverage is 100% and the single optional parameter trust_vault is documented in full detail in the schema, including its precondition and effect. The description adds no additional parameter meaning of its own, so the baseline of 3 applies.

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 opens with a concrete verb and resource ('Show this machine's fmrl key') and then enumerates exactly what is returned: key prefix and name, monthly free publishes and reset time, account attachment and canvas location, key ring location, and plugin currency. This is specific enough that an agent can distinguish it from fmrl_status or fmrl_attach without reading any schema.

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

Usage Guidelines5/5

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

It gives explicit triggering questions ('which fmrl key or account the agent uses, how many publishes are left, or whether private page keys are synced') and then names two alternatives with the conditions that select them: fmrl_status for version and connection health, fmrl_attach to attach the agent. Both when-to-use and when-not-to-use are stated.

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

Deploy Server