Skip to main content
Glama
OurFamilyWizard MCP

OurFamilyWizard MCP

by chrischall

ofw_send_message

Destructive

Send an OurFamilyWizard message from a draft or fresh compose; revision guards refuse changed or already-sent drafts and flag unconfirmed sends.

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: OurFamilyWizard keeps no files on drafts, so when sending by draftId the files ofw_save_draft HELD for it are attached automatically; myFileIDs (from ofw_upload_attachment) overrides them, or attaches files on a fresh compose; inlineAttachments/blobKeys upload new ones. Files are attached as they are (PRIVATE files attach fine); new files are uploaded PRIVATE, only after the send is approved. The response verifies them against the sent message (attachments.verified/missing). 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

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).
blobKeysNoHosted deployments: blobKeys from ofw_upload_attachment uploadSlots whose files you have already PUT. Each is uploaded to My Files as PRIVATE, attached alongside any myFileIDs, and deleted from the upload store.
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".
inlineAttachmentsNoFiles to attach, supplied as base64 BYTES ({filename, contentBase64, mimeType?}). Each is uploaded to My Files as PRIVATE and attached alongside any myFileIDs (a send attaches PRIVATE files as they are). Use for small files; on a hosted deployment, larger files (phone photos) go faster through ofw_upload_attachment uploadSlots + blobKeys here. Every entry is validated before anything is uploaded.
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. Changed2 schema fields changedv2.27.2
    • addedInput schema / properties / blobKeys
      Added value: +{
      +  "description": "Hosted deployments: blobKeys from ofw_upload_attachment uploadSlots whose files you have already PUT. Each is uploaded to My Files as PRIVATE, attached alongside any myFileIDs, and deleted from the upload store.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
    • addedInput schema / properties / inlineAttachments
      Added value: +{
      +  "description": "Files to attach, supplied as base64 BYTES ({filename, contentBase64, mimeType?}). Each is uploaded to My Files as PRIVATE and attached alongside any myFileIDs (a send attaches PRIVATE files as they are). Use for small files; on a hosted deployment, larger files (phone photos) go faster through ofw_upload_attachment uploadSlots + blobKeys here. Every entry is validated before anything is uploaded.",
      +  "items": {
      +    "properties": {
      +      "contentBase64": {
      +        "description": "The file's bytes, standard base64 (line breaks and a \"data:<type>;base64,\" prefix are tolerated).",
      +        "type": "string"
      +      },
      +      "filename": {
      +        "description": "Filename the upstream will show — a bare name, no path, not starting with a dot. Its extension sets the MIME type when mimeType is omitted.",
      +        "type": "string"
      +      },
      +      "mimeType": {
      +        "description": "MIME type, e.g. \"image/jpeg\". Default: inferred from the filename extension.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "filename",
      +      "contentBase64"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
  2. Changed1 schema field changedv2.19.4
    • 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"
      +}
  3. Changed1 schema field changedv2.17.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. 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)."
  5. First observedv2.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say destructive/open-world/non-readonly; the description supplies the far richer behavior: server-side draft re-read, refusal on revision mismatch, automatic draft deletion only after confirmation, SEND_UNCONFIRMED on timeout, PRIVATE attachment handling, and a confirmation-preflight flow. This is exactly the context annotations cannot carry.

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?

Front-loaded with the irreversible-operation warning and organized into TO SEND / RECIPIENTS / TO COMPOSE / ATTACHMENTS / response blocks, which suits a 13-parameter tool. It is dense and capitalized throughout, and the confirmation/confirmToken mechanics are stated twice, so it is not maximally tight.

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 destructive send with no output schema, it covers everything an agent needs: preflight confirmation, what is deleted and when, failure retention semantics, retry prohibition, attachment verification, and the named response fields (sentMessageId, draftKey, threaded, draftDeleted, draftRetained).

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 the baseline is 3; the description still adds non-obvious meaning — that recipientIds is usually required even for drafts, that omitting myFileIDs carries the draft's held files, and that omitting expectedRevision compares against the local cache rather than sending blind. Most of the rest is echoed from the schema.

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 and resource ("Send a message via OurFamilyWizard") and immediately distinguishes itself from every sibling by naming it as "the ONE irreversible operation here" versus ofw_save_draft, ofw_upload_attachment, and the read tools.

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?

Gives explicit routing: "TO SEND AN EXISTING DRAFT (the safe default): pass draftId" versus "TO COMPOSE FROM SCRATCH: supply subject/body/recipientIds with no draftId", plus guardrails on when to use force and when not to retry (SEND_UNCONFIRMED). Alternatives and exclusions are both stated.

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