Skip to main content
Glama
chrischall

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ofw_send_message

Destructive

Send a message or an existing draft on OurFamilyWizard, refusing to send if the draft changed, and deleting it only after confirmed delivery.

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. 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.

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.
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. Changed10 schema fields changedv2.14.0
    • changedInput schema / properties / body / description
      Previous value: -"Message body text. Required unless messageId/draftId references a cached draft."New value: +"Message 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)."
    • addedInput schema / properties / deleteDraftOnSuccess
      Added value: +{
+  "description": "Default 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.",
+  "type": "boolean"
+}
    • changedInput schema / properties / draftId / description
      Previous value: -"Legacy synonym for messageId. If both are passed they must be equal."New value: +"ID 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."
    • addedInput schema / properties / expectedRevision
      Added value: +{
+  "description": "With 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\".",
+  "type": "string"
+}
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Default 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.",
+  "type": "boolean"
+}
    • changedInput schema / properties / messageId / description
      Previous value: -"ID of an existing draft to send. When set, missing subject/body/recipientIds default to the draft's cached values, and the draft is deleted after sending."New value: +"Synonym for draftId (if both are passed they must be equal)."
    • changedInput schema / properties / myFileIDs / description
      Previous value: -"Attachment file ids (from ofw_upload_attachment) to attach to the message"New value: +"Attachment 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."
    • changedInput schema / properties / recipientIds / description
      Previous value: -"Array of recipient user IDs (get from ofw_get_profile). Required unless messageId/draftId references a cached draft."New value: +"Array of recipient user IDs (get from ofw_get_profile). Usually required even when sending a draft: OurFamilyWizard does not persist recipients on drafts."
    • changedInput schema / properties / replyToId / description
      Previous value: -"ID of the message being replied to"New value: +"ID of the message being replied to. Defaults to the draft's stored reply target when sending by draftId."
    • changedInput schema / properties / subject / description
      Previous value: -"Message subject. Required unless messageId/draftId references a cached draft."New value: +"Message subject. Required unless draftId/messageId is given (then it overrides the server draft's subject)."
  2. First observedv2.8.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description reveals critical runtime behaviors: the tool re-reads the server version, refuses on revision mismatch or already-sent draft, deletes the source draft only after confirmation, always retains it on failure, and may rewrite replyToId from cache. This is exactly the kind of consequence disclosure an agent needs before invoking an irreversible operation.

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

Conciseness5/5

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

The text is long but tightly organized with SCREAMING-header segments for draft sending, recipients, post-send behavior, fresh compose, and attachments. The irreversibility warning is front-loaded, and every sentence conveys a behavioral rule or condition rather than 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?

For a 10-parameter, zero-required-parameter mutation tool with only destructiveHint and no output schema, this definition is exceptionally complete. It describes the response fields (sentMessageId, draftKey, threaded, draftDeleted, draftRetained), success/failure handling, attachment behavior, and the draft deletion guarantee, so an agent has enough context to call it 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?

Even though schema coverage is 100%, the description adds cross-parameter meaning that the schema alone does not carry: draftId and messageId are synonyms, subject/body override only when provided, myFileIDs overrides draft attachments when sending by draftId, and expectedRevision asserts the exact version being sent. It clarifies the interaction between parameters and the guard mechanics, not just individual field types.

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 precise verb and object — 'Send a message via OurFamilyWizard' — and immediately distinguishes this from drafting/saving by framing it as the irreversible, guarded operation. It then lays out two concrete modes (send existing draft vs compose from scratch), so an agent can tell exactly what the tool accomplishes.

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 usage branches: use draftId/messageId to send an existing draft, no draftId to compose fresh, and states when recipientIds is still required because OFW does not persist recipients. It also explains when to keep the draft via deleteDraftOnSuccess:false and when the send is refused, giving clear conditions for invocation without relying on inference.

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