Skip to main content
Glama
Sign In
OurFamilyWizard MCP

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ofw_list_drafts

Lists OurFamilyWizard draft messages in one call, syncing the local cache first when unverified so results are server-confirmed; set verify:false for cache-only.

Instructions

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 complete boolean describing the RESULT SET: true means "these are ALL the drafts on OurFamilyWizard as of freshness.asOf" — check it before saying "you have N drafts". Each draft carries its draftKey (stable across the create-then-delete churn of editing) when one is known. An empty result from a cache that is not verified-fresh is REFUSED (result:"UNVERIFIED_EMPTY"); pass autoRefresh:true to sync and answer instead.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default 1)
sizeNoDrafts per page (default 50)
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact omits OurFamilyWizard's raw `listData` echo, which duplicates this draft's own id, subject, modifiedAt and recipients. `revision`, `draftKey` and `cacheStatus` are kept on both rungs.
verifyNoDefault true: when the drafts cache is not verified-fresh, run a drafts sync first (cheap — one list page plus one detail per draft) so the response is server-confirmed in one call. Set false to serve straight from the local cache with no OFW requests.
autoRefreshNoIf the result comes back EMPTY from a cache that is not verified-fresh, sync the backing folders first and answer from the refreshed cache instead of refusing. Defaults to the OFW_AUTO_REFRESH env var (false unless set), in which case the call refuses with result:"UNVERIFIED_EMPTY" and names the remedy. Costs OFW requests when it fires.

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. Changed1 schema field changedv2.15.1
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact omits OurFamilyWizard's raw `listData` echo, which duplicates this draft's own id, subject, modifiedAt and recipients. `revision`, `draftKey` and `cacheStatus` are kept on both rungs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. Changed1 schema field changedv2.14.0
    • addedInput schema / properties / verify
      Added value: +{
+  "description": "Default true: when the drafts cache is not verified-fresh, run a drafts sync first (cheap — one list page plus one detail per draft) so the response is server-confirmed in one call. Set false to serve straight from the local cache with no OFW requests.",
+  "type": "boolean"
+}
  4. Changed1 schema field changedv2.9.2
    • addedInput schema / properties / autoRefresh
      Added value: +{
+  "description": "If the result comes back EMPTY from a cache that is not verified-fresh, sync the backing folders first and answer from the refreshed cache instead of refusing. Defaults to the OFW_AUTO_REFRESH env var (false unless set), in which case the call refuses with result:\"UNVERIFIED_EMPTY\" and names the remedy. Costs OFW requests when it fires.",
+  "type": "boolean"
+}
  5. First observedv2.8.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing side effects (a sync of one list page plus one detail per draft runs first), cost implications ('Costs OFW requests when it fires'), a refusal path with a specific result code, and the stability guarantee of draftKey. This is exactly the behavioral context an agent needs before calling.

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-loads the single most important fact (one-call verification) and stays on topic throughout. It is dense and slightly repetitive ('ONE call' / 'without a second call' / 'in one call'), which costs a bit of tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the return semantics: the `complete` boolean over the result set, the `draftKey` field, and the `result:"UNVERIFIED_EMPTY"` case. It omits other error/edge results and any note on pagination interaction with `complete`, which is a minor gap for a 5-param list tool.

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 per-parameter docs already carry the baseline. The description still adds value by explaining the interaction between verify and autoRefresh and tying them to the refusal behavior, which the isolated schema entries do not connect.

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 specific verb+resource ('List draft messages') and immediately scopes it ('verified against OurFamilyWizard in ONE call'). It is clearly separable from the sibling write tools ofw_save_draft and ofw_delete_draft, and the verification framing distinguishes it from a plain cached list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit conditions: verify:true (default) for server-confirmed answers, verify:false for pure cache reads, and autoRefresh:true to escape the UNVERIFIED_EMPTY refusal. It does not name adjacent siblings (ofw_check_freshness, ofw_sync_messages) as alternatives, so the routing is internal to the tool rather than cross-tool.

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