fmrl

Read a fmrl.site page

fmrl_get

Idempotent

Read an fmrl.site page by ID or link to get its metadata and a chosen revision's content, enabling you to open shared or inbox pages and save large pages locally.

Instructions

Read one fmrl.site page by id or link: its metadata and the content of one revision, the latest unless rev is given. Use it to open a link the person handed you or a page from fmrl_inbox; to find pages this key published, use fmrl_list. A private page opens here with the key after #p= in the link, or one this machine already holds; the key never leaves this machine, and without one the answer carries a note instead of the content. Reading a revision of a page you watch marks it seen. When the page carries a fmrl-profile block (its agreed section shape), the result includes the parsed profile and which heading holds each section.

Input Schema

Name	Required	Description
`id`	Yes	A page id or page URL, optionally with its private key (#p=). A /c/ recovery link is not a page URL.
`rev`	No	The revision to read; the latest when left out.
`to_file`	No	true: write the content, as it reads after opening, to <id>.md or <id>.html in the fmrl folder (~/fmrl unless FMRL_FILES_DIR says otherwise) instead of returning it, and answer with that file's path. It replaces an earlier copy of the same page. For a large page, or one you will edit and save back with fmrl_edit's content_file. The file is readable only by this user.

Output Schema

Name	Required	Description	Default
`id`	Yes
`cid`	No
`rev`	Yes
`url`	Yes
`size`	Yes
`title`	No
`editor`	Yes
`format`	Yes
`pinned`	Yes
`status`	Yes
`content`	No
`missing`	No
`private`	Yes
`profile`	No
`key_held`	No
`expires_at`	Yes
`latest_rev`	Yes
`section_map`	No
`content_file`	No
`content_note`	No
`profile_error`	No
`content_format`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.17.8Nov 9, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / rev / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / section_map / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
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?

Beyond the annotations it discloses genuinely non-obvious behavior: a private page needs the key after #p= or one held by this machine, the key never leaves the machine, and without a key the response carries a note rather than content. It also explains the side effect that reading a revision of a watched page marks it seen, which accounts for readOnlyHint=false. It stops short of describing how the note or profile parsing failures appear, but the coverage is well above the annotation baseline.

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?

Purpose and the sibling distinction are front-loaded, and each clause carries information (addressing modes, alternatives, key handling, side effect, profile shape). It is dense rather than padded, though the key-handling and profile sentences could be tightened into fewer words.

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 read tool with three fully documented parameters, annotations, and an output schema, the description covers what an agent needs: what is returned, the fallback without a key, the seen-marking side effect, and the profile parsing behavior. Nothing required for a correct call 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%, so all three parameters are already documented, and the description largely restates them ('one revision, the latest unless rev is given'). It adds only slight framing around the embedded private key in the id, with no new syntax or edge-case detail beyond the schema's own note about /c/ recovery links.

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 opening sentence names a specific verb and resource (read one fmrl.site page) plus the addressing modes (id or link) and the revision scope (latest unless rev is given). It then explicitly distinguishes itself from fmrl_list, so an agent can route between them without opening either 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 states concrete when-to-use cases ('open a link the person handed you or a page from fmrl_inbox') and names the alternative for the other case ('to find pages this key published, use fmrl_list'). The private-page rule further tells the agent what input it needs before calling.

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

Deploy Server