Skip to main content
Glama
Sign In
OurFamilyWizard MCP

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ofw_check_freshness

Destructive

Verify whether cached OurFamilyWizard folder counts and message states still match the server without running a full sync. Confirms if a draft is still unsent before you rely on it.

Instructions

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 state — "draft" | "sent" | "received" | "deleted" | "unknown" — alongside folder, sentAt, existsOnServer and a content comparison. state is the field that answers "is this still a draft?": a draft that has been SENT still exists on the server, so existsOnServer:true never distinguished the two. A cached draft whose state is no longer "draft" reports inSync:false even when its text is byte-identical. Content is compared by revision hash, because OFW draft timestamps do NOT change when a draft is edited in the web app. Does not fetch bodies into the cache, does not touch attachments, and does not depend on sync state. For draftKeys, or a full live draft inventory, use ofw_status.

Input Schema

NameRequiredDescriptionDefault
foldersNoFolders to compare cached vs live counts for. Defaults to all three when messageIds is not given. Must be non-empty if given.
messageIdsNoSpecific ids to verify against OFW (max 25). Ids cached as drafts, as sent messages, or as already-read inbox messages are probed freely — none of those can stamp the record. Anything else is skipped — see allowMarkRead.
allowMarkReadNoDefault false. Probing an id whose cached state cannot rule out an unread INBOX message requires fetching its detail, which marks it READ on OurFamilyWizard and stamps a co-parent-visible "First Viewed" time — irreversible. Such ids are skipped (reason:"WOULD_MARK_READ") unless you set this to true. The server-wide OFW_ALLOW_MARK_READ=false is a ceiling this cannot raise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Changed2 schema fields changedv2.9.2
    • changedInput schema / properties / allowMarkRead / description
      Previous value: -"Default false. Probing an id that is NOT a cached draft requires fetching its detail, which marks an unread inbox message as READ on OurFamilyWizard — an irreversible change to the record. Such ids are skipped unless you set this to true."New value: +"Default false. Probing an id whose cached state cannot rule out an unread INBOX message requires fetching its detail, which marks it READ on OurFamilyWizard and stamps a co-parent-visible \"First Viewed\" time — irreversible. Such ids are skipped (reason:\"WOULD_MARK_READ\") unless you set this to true. The server-wide OFW_ALLOW_MARK_READ=false is a ceiling this cannot raise."
    • changedInput schema / properties / messageIds / description
      Previous value: -"Specific ids to verify against OFW (max 25). By default only ids present in the drafts cache are probed — see allowMarkRead."New value: +"Specific ids to verify against OFW (max 25). Ids cached as drafts, as sent messages, or as already-read inbox messages are probed freely — none of those can stamp the record. Anything else is skipped — see allowMarkRead."
  3. First observedv2.8.0

TDQS

A4.8/5.0
Behavior5/5

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

With destructiveHint=true and readOnlyHint=false set, the description explains exactly why: probing certain ids fetches detail, marks the message READ on OFW and stamps a co-parent-visible, irreversible 'First Viewed' time, and it notes OFW_ALLOW_MARK_READ as a server-wide ceiling. It also discloses the cost model (one request per folder plus one per messageId), which no annotation conveys.

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 purpose, then cost, then return semantics, then exclusions — a sensible order. It is dense and longer than average, and a few clauses (e.g. the byte-identical/inSync example) could be tightened, but nearly every sentence carries non-redundant information.

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?

No output schema exists, and the description compensates fully: it lists the returned fields (live vs cached count, state enum values, folder, sentAt, existsOnServer, inSync) and explains the surprising semantics of each. Nothing needed to call this tool correctly is missing.

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, but the description adds real meaning: it explains the per-folder live-vs-cached count comparison, the per-id lifecycle state field and why existsOnServer alone cannot distinguish draft from sent, and that content is compared by revision hash because draft timestamps do not change on edit.

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?

States a precise verb+resource: cheaply confirm whether the local cache still matches OurFamilyWizard without a full sync. It is clearly distinguished from the sync tool and from ofw_status, and the 'freshness' framing is immediately actionable.

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 says when to use it ('before asserting anything about current state — especially "draft X is still sitting unsent"') and names the alternative for a different need ('For draftKeys, or a full live draft inventory, use ofw_status'). It also states what it deliberately does not do (bodies, attachments, sync state).

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