Skip to main content
Glama
chrischall

ofw-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ofw_send_message

Destructive

Compose and send messages in OurFamilyWizard, or safely deliver an existing draft after verifying it hasn't been changed; failed sends keep the draft intact and send nothing.

Instructions

Send a message via OurFamilyWizard — the ONE irreversible operation here, so it carries the strongest guard. TO SEND AN EXISTING DRAFT (the safe default): pass draftId (or messageId — same thing). The tool re-reads the draft from OFW and sends the SERVER'S version, so what goes out is what is on OurFamilyWizard, not what this session remembers — subject/body act only as explicit overrides. It is guarded exactly like ofw_save_draft: pass expectedRevision to assert which version you are sending; if the draft changed on OFW since you read it — or no longer exists (it may already have been SENT) — the send is REFUSED with the current server content echoed back, and nothing goes out. RECIPIENTS: OurFamilyWizard does not persist recipients on drafts, so recipientIds is usually still required at send time (ids from ofw_get_profile). After the send is CONFIRMED (OFW returned the new message id and the re-fetched sent record matches what was posted), the source draft is deleted automatically; pass deleteDraftOnSuccess:false to keep it. On ANY failure or ambiguity the draft is never deleted — the response carries draftRetained:true with the reason. If the send request times out or drops without a definitive answer, the result is SEND_UNCONFIRMED: the message may already have been delivered, so do NOT retry until a sent-folder sync (or ourfamilywizard.com) shows it did not go out. TO COMPOSE FROM SCRATCH: supply subject/body/recipientIds with no draftId. If replyToId is provided (or inherited from the draft), the cache may rewrite it to the latest reply in the same thread (a note is included when this happens). ATTACHMENTS: when sending by draftId, the server draft's own attachments carry over automatically; myFileIDs (from ofw_upload_attachment) overrides or attaches files on a fresh compose. The response leads with sentMessageId and the stable draftKey, and reports threaded (whether OFW actually linked the reply) and draftDeleted. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call performs NO write and returns a preview of exactly what would happen plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoMessage body text. Required unless draftId/messageId is given (then it overrides the server draft's body — omit it to send exactly what is on OurFamilyWizard).
forceNoDefault false. Send even when the draft changed on OurFamilyWizard since you read it, or its current state could not be read. Only use after showing the user the conflict.
draftIdNoID of an existing draft to send. The draft is re-read from OurFamilyWizard and its SERVER content is sent; missing subject/body default from it. Guarded: a draft that changed since you read it, or that was already sent/deleted, refuses rather than sending blind.
subjectNoMessage subject. Required unless draftId/messageId is given (then it overrides the server draft's subject).
messageIdNoSynonym for draftId (if both are passed they must be equal).
myFileIDsNoAttachment file ids (from ofw_upload_attachment) to attach to the message. When sending by draftId, omit it to carry the server draft's own attachments over; passing it overrides them.
replyToIdNoID of the message being replied to. Defaults to the draft's stored reply target when sending by draftId.
confirmTokenNoONLY 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.
recipientIdsNoArray of recipient user IDs (get from ofw_get_profile). Usually required even when sending a draft: OurFamilyWizard does not persist recipients on drafts.
expectedRevisionNoWith draftId: the `revision` from ofw_list_drafts / ofw_get_message / ofw_check_freshness for that draft. Asserts you are sending THAT version; if the draft changed on OFW since, the send is refused and the current server content returned. Omit and the tool compares the server against the local cache instead — omitting never means "send whatever is there now".
deleteDraftOnSuccessNoDefault true. Delete the source draft after — and ONLY after — the send is confirmed (new message id returned and the re-fetched sent record checks out). Set false to keep the draft. On a failed or unverifiable send the draft is ALWAYS kept, regardless of this flag.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.19.4

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only indicate a destructive write (readOnlyHint=false, destructiveHint=true), but the description discloses a wealth of behavioral detail: the irreversible deletion of the source draft, guard/refusal on revision mismatch, SEND_UNCONFIRMED uncertainty, automatic deletion only after confirmation, cache rewriting of replyToId, and the two-step confirmation fallback. It even explains what happens on timeout or failure, leaving little to the agent's imagination.

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

Conciseness2/5

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

The description is an extensive multi-paragraph monologue, likely over a thousand words, and repeats information already present in the input schema (e.g., deleteDraftOnSuccess, expectedRevision, force). While the key warning is front-loaded, the density of parentheticals and redundant explanations makes it hard to scan, and much could be condensed into a structured summary.

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?

Given the tool's complexity—11 parameters, no output schema, destructive side effects, confirmation flow—the description is exceptionally complete. It covers the response shape (sentMessageId, draftKey, threaded, draftDeleted), the SEND_UNCONFIRMED edge case, attachment inheritance, and the confirmation fallback, so an agent has all necessary context to invoke the tool correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds crucial semantic interconnections: draftId/messageId refer to the server's version, subject/body act as explicit overrides, expectedRevision asserts a specific version, recipientIds are still required because OFW does not persist draft recipients, myFileIDs override server attachments, and confirmToken has a strictly defined lifecycle. These nuances go far beyond the per-parameter schema descriptions.

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 clearly states the tool sends a message via OurFamilyWizard and explicitly labels it 'the ONE irreversible operation here', distinguishing it from siblings like ofw_save_draft and ofw_delete_draft. It further breaks down two distinct use modes (sending an existing draft vs composing from scratch), leaving no ambiguity about the tool's purpose.

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?

Provides explicit when-to-use guidance: the safe default of sending a draft via draftId, when to compose fresh, when force may be used after user confirmation, and a concrete directive to avoid retry on SEND_UNCONFIRMED until a sync verifies the message did not send. It also references ofw_save_draft's guarding mechanism and warns that recipientIds are usually still required, making alternative selection clear.

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

Deploy Server

Other Tools