OurFamilyWizard MCP

ofw_get_message

Destructive

Fetches a single OurFamilyWizard message or draft by ID, using cached content when available and preventing accidental read-state changes on unread inbox messages.

Instructions

Get a single OurFamilyWizard message OR draft by ID. Reads from local cache when available; otherwise fetches from OFW — and for an UNREAD INBOX message that fetch marks it read and stamps a "First Viewed" time the co-parent can see, which is part of the record and cannot be undone. Pass allowMarkRead:false to refuse such a fetch instead (cached bodies, sent messages and already-read messages are unaffected, because none of them stamp anything). For ids that match a draft (in the drafts cache), the response carries folder="drafts" and the body/subject/recipients reflect the drafts cache (which ofw_sync_messages keeps fresh) — drafts have no fromUser, and sentAt/fetchedBodyAt mirror the draft's modifiedAt. For inbox/sent messages, folder is "inbox" or "sent" as before. On a server-configured no-read day (OFW_READ_DAYS / OFW_NO_READ_DAYS) inbox/sent bodies are withheld (body:null, bodyWithheld:true, readingBlocked says when reading resumes) and OFW is never contacted. When the server runs with OFW_CONFIRM_MARK_READ=true, opening an unread inbox message first shows its subject, sender and sent time and asks the user to confirm marking it read: a confirmation prompt where the client supports one; otherwise the first call fetches NOTHING and returns that preview plus a confirmToken, and only a repeat call with that token opens the message (see MCP_CONFIRM_MODE). Show the user the preview and wait for their yes before repeating the call.

Input Schema

Name	Required	Description
`view`	No	Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact omits OurFamilyWizard's raw `listData` echo, which duplicates this record's own id, subject, sentAt, recipients and read flag; the sender is promoted to `from`, and `files`/`replied` are kept. Pass "full" for the echo.
`messageId`	Yes	Message ID (also accepts draft IDs — drafts are routed via the drafts cache)
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
`allowMarkRead`	No	Default true (the long-standing behaviour). Set false to refuse a fetch that would mark an unread INBOX message as READ on OurFamilyWizard — an irreversible, co-parent-visible change to the record. Reads that cannot stamp anything (a cached body, a sent message, an already-read message) still succeed. The server-wide OFW_ALLOW_MARK_READ=false is a ceiling this argument cannot raise.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.26.1Nov 5, 2026

addedInput schema / properties / confirmToken

Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}

Changed1 schema field changedv2.17.0Sep 17, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedv2.15.1Sep 5, 2026

addedInput schema / properties / view

Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact omits OurFamilyWizard's raw `listData` echo, which duplicates this record's own id, subject, sentAt, recipients and read flag; the sender is promoted to `from`, and `files`/`replied` are kept. Pass \"full\" for the echo.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}

First observedv2.8.0Jul 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description backs that up with specifics the annotations cannot convey: the unread-inbox fetch marks the message read and stamps a co-parent-visible "First Viewed" time that cannot be undone. It further discloses no-read-day withholding (body:null, bodyWithheld:true, readingBlocked) and the OFW_CONFIRM_MARK_READ preview/confirmToken mechanics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, but the body is a dense, em-dash-heavy block with nested parentheticals and a dangling pointer to MCP_CONFIRM_MODE. The content is largely valuable, yet the confirmation-flow material could be broken into distinct clauses rather than run together in one paragraph.

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?

For a tool with no output schema and a possible irreversible side effect, the description does substantial work: it describes the response shape (folder=drafts, missing fromUser, sentAt mirroring modifiedAt, bodyWithheld/readingBlocked) and the two confirmation modes. The main gap is the unexplained "see MCP_CONFIRM_MODE" reference, which leaves the client-side branching underspecified.

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 each parameter is already documented, but the description adds cross-parameter interaction the schema does not: allowMarkRead only governs fetches that would stamp something, and confirmToken is only meaningful on a repeat call after a phase-1 preview. It also clarifies that messageId accepts draft IDs routed via the drafts cache.

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?

Opens with a specific verb, resource and scope: "Get a single OurFamilyWizard message OR draft by ID." It also declares the data source (local cache, falling back to OFW), which distinguishes it from ofw_list_messages and ofw_list_drafts in the sibling set.

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?

Explicitly states when to pass allowMarkRead:false to refuse a read-stamping fetch, and which cases are unaffected (cached bodies, sent messages, already-read messages). It also gives a concrete operational instruction for the confirmation flow: show the preview and wait for the user's yes before repeating the call.

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

ofw_get_message

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools