OurFamilyWizard MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OFW_PASSWORD | No | Your OurFamilyWizard password (required for env-var auth path) | |
| OFW_USERNAME | No | Your OurFamilyWizard email address (required for env-var auth path) | |
| OFW_WRITE_MODE | No | Write protection level: 'none', 'drafts', or 'all' | all |
| OFW_CACHE_IDENTITY | No | Optional label for separate caches when using multiple accounts with fetchproxy | |
| OFW_ALLOW_MARK_READ | No | Set to 'false' to prevent marking messages as read | |
| OFW_CALENDAR_WRITES | No | Set to 'true' to enable calendar writes when OFW_WRITE_MODE is 'drafts' | |
| OFW_DISABLE_FETCHPROXY | No | Set to '1' to skip fetchproxy fallback, making missing credentials a hard error | |
| OFW_FETCH_UNREAD_BODIES | No | Set to 'true' to fetch unread message bodies during sync by default | |
| OFW_FRESHNESS_TTL_SECONDS | No | Cache freshness threshold in seconds | 300 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ofw_healthcheckA | Resolves the credential the way real tools do, then makes one authenticated request to ourfamilywizard.com. Reports which source supplied the credential, whether ourfamilywizard.com accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a ourfamilywizard.com-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke. |
| ofw_get_profileA | Get current user and co-parent profile information from OurFamilyWizard |
| ofw_get_notificationsA | Get OurFamilyWizard dashboard summary: unread message count, upcoming events, outstanding expenses. Note: updates your last-seen status. |
| ofw_list_message_foldersA | List OurFamilyWizard message folders (inbox, sent, etc.) and their unread counts. Fetched LIVE from OFW, so the counts are current. Returns folder IDs needed to call ofw_list_messages. Does NOT return message content. |
| ofw_list_messagesA | List messages from the local OurFamilyWizard cache. Supports filtering by folder, date range, and a substring query on subject+body. Pagination is offset-based (1-based |
| ofw_get_messageA | 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 |
| ofw_send_messageA | 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. |
| ofw_list_draftsA | List draft messages, verified against OurFamilyWizard in ONE call: when the local drafts cache is not verified-fresh, a cheap drafts sync runs first by default (verify:true), so the answer is server-confirmed without a second call. Pass verify:false to answer purely from the cache (no OFW requests). Returns an explicit |
| ofw_save_draftA | Save a message as a draft in OurFamilyWizard. RECIPIENTS: OurFamilyWizard does NOT persist recipients on drafts — recipientIds are accepted but the saved draft comes back with none (documented OFW behavior, noted once in the response, not warned about; supply recipientIds at send time instead). IDENTITY: the response leads with |
| ofw_delete_draftA | Delete a draft message from OurFamilyWizard. Also removes the draft from the local cache. Before deleting, the draft is re-read from OFW and the delete is REFUSED if it changed since you last read it (the current server body is returned so nothing is lost) — pass expectedRevision to assert which version you mean, or force:true to delete regardless. |
| ofw_get_unread_sentA | List sent messages that have not been read by one or more recipients. Reads from local cache. Returns |
| ofw_upload_attachmentA | Upload a local file to OurFamilyWizard's "My Files" so it can be attached to a message. Returns the fileId — pass that to ofw_send_message or ofw_save_draft in myFileIDs to attach it. The file is uploaded as PRIVATE (visible only to you) by default; pass shareClass:"SHARED" to share with co-parents directly via the My Files area. |
| ofw_download_attachmentA | Download an OFW message attachment by fileId and return content you can actually read. Inline delivery walks a ladder and returns the first rung that works: (1) host-renderable images (PNG/JPEG/GIF/WEBP) come back as ImageContent; (2) .xlsx/.csv/.tsv, .pdf, .docx, .pptx and text files come back as EXTRACTED CONTENT — per-sheet CSV, per-page/slide text, document text — in the response JSON under |
| ofw_sync_messagesA | Sync messages from OurFamilyWizard into the local cache. Returns counts per folder and a list of unread inbox messages whose bodies were NOT fetched (to avoid mark-as-read on OFW). Call ofw_get_message(id) on those to read them. EVERY call re-checks the newest page first, so new messages are picked up promptly even while an old-history backfill is still running; only then does it spend what is left of its budget advancing that backfill. Pass deep:true to walk all OFW pages instead of stopping at the first all-cached page (use to backfill suspected gaps). Sync is BOUNDED and RESUMABLE: on hosted deployments a per-call OFW-request budget (env OFW_SYNC_MAX_REQUESTS, or the maxRequests argument) caps how far one call walks; when the budget is hit the response reports done:false with a note — call again with the SAME arguments to resume. done:false means older history is still being backfilled; it does NOT mean recent messages are missing. Local installs are unbounded by default (done is always true). |
| ofw_check_freshnessA | Cheaply confirm whether the local cache still matches OurFamilyWizard, WITHOUT running a full sync. Use this before asserting anything about current state — especially "draft X is still sitting unsent". Costs one OFW request for the folder check plus one per messageId. For each folder it returns the live server count next to the cached count. For each id it returns a LIVE lifecycle |
| ofw_statusA | ONE live call that answers "where does everything stand?". This is the call that should back any status summary about drafts or specific messages — never session memory, and never a cached read alone. With no arguments it returns the FULL current draft inventory, verified against OurFamilyWizard. Pass ids and/or draftKeys to get each one's live lifecycle |
| ofw_list_eventsA | List OurFamilyWizard calendar events in a date range |
| ofw_create_eventA | Create a calendar event in OurFamilyWizard. Unless privateEvent is true, the event is immediately visible to the co-parent — there is no draft stage. |
| ofw_update_eventA | Update an existing OurFamilyWizard calendar event. Fetches the event, applies the given changes, and writes the merged result back (OFW has no partial update). |
| ofw_delete_eventA | Delete an OurFamilyWizard calendar event |
| ofw_get_expense_totalsA | Get OurFamilyWizard expense summary totals (owed/paid) |
| ofw_list_expensesA | List OurFamilyWizard expenses. Offset-paged via start/max. The response leads with its paging state — |
| ofw_create_expenseB | Log a new expense in OurFamilyWizard |
| ofw_list_journal_entriesA | List OurFamilyWizard journal entries. Offset-paged via start/max (1-based). The response leads with its paging state — |
| ofw_create_journal_entryB | Create a new journal entry in OurFamilyWizard |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 25 tools
Most tools have distinct resource-action targets, but the messaging cluster is dense: list_messages, get_unread_sent, list_drafts, status, check_freshness, and sync_messages all overlap around reading or verifying message/draft state. The long descriptions help, but an agent could easily pick the wrong freshness or listing tool.
The overwhelming majority follow an ofw_verb_noun pattern, e.g. create_event, list_expenses, send_message, delete_draft. A few deviations like ofw_status, ofw_healthcheck, and ofw_get_unread_sent break the pattern slightly, but the convention is still predictable and readable.
25 tools sits at the heavy end of the borderline range. The broad domain justifies a decent number, but roughly half the surface is dedicated to messaging/drafts, making the set feel larger and more redundant than necessary.
Calendar and messaging lifecycles are well covered, but journal entries only support create/list and expenses lack update/delete, leaving obvious CRUD gaps. There is also no single-event get, though the date-range list partially mitigates that.