Skip to main content
Glama
chrischall

ofw-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ofw_status

Read-only

Get live status of drafts and messages, verified against OurFamilyWizard. Returns full draft inventory or resolves specific ids/draftKeys to their current state (draft, sent, received, deleted).

Instructions

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 state ("draft" | "sent" | "received" | "deleted" | "unknown") with sentAt and viewedAt. A draftKey is the stable identity ofw_save_draft returns: editing a draft mints a new OFW id every time (create-then-delete), so the key is the only way to ask "what happened to the thing I was working on?" — it resolves to the chain's current id and keeps resolving after the draft is SENT (state:"sent" with sentMessageId). The top-level complete is true ONLY when every part of this snapshot was verified live; if it is false, do not state a draft count or a lifecycle claim from this payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoMessage/draft ids to resolve to a live state (combined with draftKeys, max 25 probes per call).
draftKeysNoStable draft keys (from ofw_save_draft / ofw_list_drafts) to resolve to their CURRENT id and state.
allowMarkReadNoDefault false. An id whose cached state cannot rule out an unread INBOX message can only be probed by fetching its detail, which marks it READ on OurFamilyWizard — irreversible and co-parent-visible. Those are skipped unless this is true. Cached drafts, sent messages and already-read messages are always probed. Capped by OFW_ALLOW_MARK_READ.
includeDraftInventoryNoReturn the full current draft list, verified against OurFamilyWizard first. Defaults to TRUE when neither ids nor draftKeys is given (so a bare ofw_status() is a complete status snapshot), otherwise false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.19.4

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint, it discloses the freshness contract ('complete is true ONLY when every part... verified live'), the create-then-delete id churn behind draftKeys, and the irreversible co-parent-visible mark-read side effect gated behind allowMarkRead. This is exactly the kind of behavioral context annotations do not convey.

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 description is long but information-dense; the main purpose is front-loaded and every subsequent sentence covers a needed behavioral or parameter nuance. Nothing is filler.

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?

With no output schema, it still tells the agent what comes back: full inventory, lifecycle states, sentAt/viewedAt, and the meaning of top-level complete. It also covers defaults and safety caps, so an agent has enough to call it correctly in any mode.

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?

Although schema coverage is 100%, the description adds meaning the schema lacks: max 25 probes, draftKey stability semantics across edits and sends, the default of includeDraftInventory based on other args, and the OFW_ALLOW_MARK_READ cap. These clarify how to invoke the tool rather than just what each field is.

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 concrete job ('ONE live call that answers where does everything stand?') and specifies exactly what it returns: full verified draft inventory and per-message lifecycle state. It distinguishes itself from cached reads and session memory, so an agent can tell it apart from list/get siblings.

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?

States the intended use explicitly ('should back any status summary about drafts or specific messages') and gives negative guidance ('never session memory, and never a cached read alone'). It also defines when each parameter mode applies: bare call for a full snapshot, ids/draftKeys for targeted probes.

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