OurFamilyWizard MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.9.2
Disambiguation3/5
Several message-related tools (list_messages, get_message, get_unread_sent, check_freshness, status) have overlapping purposes and could confuse an agent. Descriptions are detailed but boundaries between them are not immediately clear.
Naming Consistency4/5
Most tools follow a verb_noun pattern with the 'ofw_' prefix. Exceptions like 'status' and 'check_freshness' break the pattern, but overall naming is predictable and consistent.
Tool Count4/5
24 tools cover many aspects of the OFW domain (messages, events, expenses, journal, attachments, profile). While slightly high, the count is justified by the complexity of the application.
Completeness3/5
The tool set covers primary CRUD for events and messages, but expenses and journal entries lack update and delete operations. This leaves notable gaps that may hinder complete workflows.
Average 4.2/5 across 24 of 24 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 23 of 23 community issues answered or closed in the last 6 months
- 156 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false, indicating non-destructive action. Description does not add behavioral details such as whether it creates a new record, what it returns, or any side effects. The agent may need more context about the operation.
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?
Single sentence, front-loaded with verb and object. Every word earns its place; no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with two required params and no output schema. Description is minimal but covers the core action. However, it lacks details on return value or post-creation behavior, which could be useful for a new expense action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'Log' and resource 'expense' clearly. However, it does not differentiate from sibling tools like ofw_list_expenses or ofw_get_expense_totals, missing a chance to clarify its unique action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like updating or deleting expenses. No prerequisites or context provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. Since annotations already declare the tool is read-only, the description does not contradict them, but it also fails to disclose any additional traits like pagination behavior or authentication requirements.
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?
The description is a single concise sentence with no unnecessary words. However, it could be improved by front-loading key information and adding structure, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 2 optional parameters and no output schema, the description lacks information about return format, default ordering, or what constitutes a journal entry. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'max' and 'start' parameters already described in the schema. The description does not add any extra meaning or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'journal entries', which is distinct from sibling tools like ofw_create_journal_entry. However, it does not explicitly differentiate from other list tools such as ofw_list_events or ofw_list_expenses, lacking specificity on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like ofw_list_events or ofw_get_notifications. No prerequisites, exclusions, or context for usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false. Description adds no additional behavioral info such as permissions, side effects, or what happens on success. Minimal disclosure.
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?
Single concise sentence with no wasted words. Perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema and fully described parameters, the description is adequate but does not mention what the tool returns (e.g., created entry ID). Missing return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'title' and 'body'. Description does not add extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
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?
Description clearly states 'Create a new journal entry' with specific verb and resource. Distinct from sibling 'ofw_list_journal_entries' which is a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There are no similar create tools among siblings, but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions pagination, which adds useful context beyond the readOnlyHint annotation. However, it lacks details on data freshness, sorting order, or what happens if pagination parameters are omitted.
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 a single sentence with no unnecessary words. It is concise and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only two simple parameters. The description is sufficient for basic understanding but lacks details on return format, pagination indicators, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'max' and 'start' parameters. The description does not add any extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List OurFamilyWizard expenses with pagination' clearly states the action (list) and resource (expenses). It is specific but does not explicitly distinguish itself from sibling tools like ofw_get_expense_totals or ofw_create_expense, though the function is inherently different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, ordering, or when to prefer it over other tools like ofw_get_expense_totals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates destructiveHint=true, so the description's 'Delete' is consistent but adds no new behavioral context (e.g., permanence, cascading effects on recurring events). It meets the minimum bar but does not exceed it.
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 a single sentence with no wasted words. It is appropriately front-loaded and easy to parse quickly.
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?
For a simple delete tool with no output schema, the description is mostly complete. However, it could briefly note that the action is irreversible or that includeFuture affects recurring events, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, so the score is baseline 3.
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?
The description clearly states the verb 'Delete' and the resource 'OurFamilyWizard calendar event'. It is distinct from sibling tools like ofw_create_event and ofw_update_event, making it easy for an agent to select this tool when deletion is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as ofw_update_event for modifications. It does not mention prerequisites or conditions under which deletion should not be performed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it lists events in a date range but no further behavioral traits (e.g., no pagination info, rate limits, or data freshness). Minimal added value beyond annotations.
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?
Single front-loaded sentence that efficiently conveys the tool's purpose. No unnecessary words.
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 simple list tool with full schema coverage and readOnlyHint annotation, the description is complete enough. No output schema required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 3 parameters. Description doesn't add additional meaning beyond the schema, so baseline of 3 is appropriate.
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?
Description clearly states it lists calendar events from OurFamilyWizard within a date range. The verb 'List' and resource 'calendar events' are specific, and it distinguishes from create/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention when not to use it or suggest other tools like ofw_create_event for adding events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context about output type (owed/paid totals) but does not disclose additional traits like time period scope.
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?
Single sentence with no wasted words. Front-loaded with verb and resource.
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?
Given no parameters and no output schema, description sufficiently conveys purpose. Could specify time period scope but not critical for basic functionality.
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?
No parameters exist; schema coverage is 100%. Description adds value by clarifying output content. Baseline 4 is appropriate.
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?
The description clearly states the verb 'Get' and resource 'expense summary totals (owed/paid)', distinguishing it from sibling tool 'ofw_list_expenses' which likely lists individual expenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ofw_list_expenses'. No explicit context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotation (destructiveHint: false), the description discloses key behavior: events are immediately visible to the co-parent unless privateEvent is set, and there is no draft stage. This adds valuable context for an agent.
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 two sentences, no waste, and the most critical behavioral detail (visibility and draft stage) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 14 parameters and no output schema, the description only covers visibility and draft behavior. It lacks explanation of return values, error cases, or interactions among parameters like children, eventParentId, or reminders. The complexity of the tool demands more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 64% schema description coverage, the baseline is 3. The description does not add new meaning to parameters beyond what the schema already provides, but it does not detract either. No parameter-specific elaboration is given.
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?
The description clearly states 'Create a calendar event in OurFamilyWizard' with a specific verb and resource. It distinguishes from siblings by highlighting the immediate visibility to co-parent and absence of a draft stage, which sets it apart from update/delete tools.
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?
The description provides guidance on when to use privateEvent (to control visibility), and implies this is for new events given the sibling tools for update and delete. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a read operation, consistent with the readOnlyHint annotation. It adds no extra behavioral details beyond what the annotation already provides.
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 a single, concise sentence that directly conveys the tool's purpose without unnecessary words.
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?
Given the simple nature of the tool (no parameters, readOnlyHint annotation), the description is complete. No output schema is needed for such a straightforward retrieval.
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?
There are no parameters, so the baseline is 4 as per guidelines. The description does not need to elaborate on parameters.
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?
The description clearly states the action (get) and the resource (current user and co-parent profile information). It implicitly distinguishes from sibling tools that handle notifications, messages, events, expenses, and journal entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when profile information is needed but provides no explicit guidance on when not to use it or alternatives. With zero parameters and no sibling profile tools, this is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation: it reveals the merge strategy (fetch, apply changes, write back). It does not contradict annotations. It lacks explicit disclosure of required permissions or irreversibility details, but the annotation covers general destructiveness.
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 two sentences: first states the purpose, second explains the merge behavior. No redundancy, efficient, and front-loaded.
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?
The description explains the crucial merge strategy, which is key for correct usage. However, it does not explicitly state that omitted fields retain their current values, nor does it describe the return value (no output schema). For a tool with 15 parameters, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema description coverage, the schema already documents most parameters. The description adds overall context about the merge operation but does not elaborate on individual parameters beyond what's in the schema. Baseline 3 is appropriate.
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?
The description clearly states 'Update an existing OurFamilyWizard calendar event.' It also explains the merge strategy, distinguishing it from create (ofw_create_event) and delete (ofw_delete_event) siblings.
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?
The description explains the fetch-merge-write approach and notes that OFW has no partial update, implying how to use parameters. However, it does not explicitly state when to use this tool versus create or delete, though the context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=false, the description does not mention any mutation, but it transparently explains caching behavior, the UNVERIFIED_EMPTY refusal scenario, and that autoRefresh may cost OFW requests. This adds important behavioral context beyond the annotation.
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?
The description is structured logically: purpose, result format, special case (UNVERIFIED_EMPTY), and reminder for live queries. It is slightly verbose but each sentence serves a purpose, and key information is front-loaded.
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?
Given no output schema, the description fully explains the result structure (complete boolean, draftKey) and error conditions (UNVERIFIED_EMPTY). It also ties into the caching mechanism via freshness.asOf, making the tool behavior clear for an agent.
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?
With 100% schema coverage, the baseline is 3, but the description adds significant value by detailing the autoRefresh parameter's behavior (including default from env var and cost implications) and the semantics of the result fields (complete boolean, draftKey).
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?
The description clearly states 'List draft messages from the local OurFamilyWizard cache' and distinguishes from the sibling tool ofw_status(includeDraftInventory:true) for a live one-call alternative. This provides a specific verb and resource, making the purpose unmistakable.
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?
The description explains when to use autoRefresh to avoid UNVERIFIED_EMPTY refusal, and explicitly mentions ofw_status as a preferred alternative for live queries. However, it lacks explicit 'when not to use' statements for other sibling tools, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the `complete` boolean semantics, the UNVERIFIED_EMPTY refusal behavior, and autoRefresh fallback. It also notes potential large result sets (1000+). Annotations (readOnlyHint: false) are consistent, and the description adds crucial context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but runs as a single paragraph. It could benefit from bullet points or structure for easier scanning. However, it remains clear and every sentence adds value.
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 7 parameters and no output schema, the description covers the return behavior (result field, `complete` boolean) and edge cases (UNVERIFIED_EMPTY). It also references caching and syncing, which is relevant given sibling tools like ofw_sync_messages and ofw_check_freshness. Lacks explicit return value structure, but adequate.
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%, but the description adds meaning: explains that `q` is a substring on subject AND body, `folderId` defaults to 'both', `since`/`until` are inclusive/exclusive, and `autoRefresh` defaults to an env var. This extra detail justifies a score above baseline 3.
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?
The description clearly states 'List messages from the local OurFamilyWizard cache' and details filtering by folder, date range, and substring query. It distinguishes from siblings like ofw_get_message (single message) and ofw_send_message (send).
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?
The description advises preferring filters over pagination ('if you know what you want...prefer the filters over walking pages') and explains when to use autoRefresh. It does not explicitly contrast with alternative tools like ofw_sync_messages or list drafts, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses default privacy (PRIVATE), the ability to share via shareClass, and the return value (fileId). Annotations only include destructiveHint: false, so the description adds useful behavioral context, though it omits details like file size limits or synchronous behavior.
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 two sentences, front-loaded with the core action and return value. Every sentence adds essential information without redundancy or wasted words.
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?
Given the tool has 4 parameters, no output schema, and minimal annotations, the description adequately explains the upload purpose, return value usage, and key parameter behavior. It connects to sibling tools for downstream attachment use. Missing details like error handling or prerequisites are acceptable for this scope.
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% with clear parameter descriptions, so baseline is 3. The description adds value by noting tilde expansion for path and reinforcing the default shareClass, providing extra semantic guidance.
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?
The description clearly states the tool uploads a local file to OurFamilyWizard's 'My Files' for message attachment, specifies the returned fileId, and distinguishes from sibling tools like ofw_send_message and ofw_save_draft by explaining how the fileId is used.
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?
The description tells when to use the tool (before sending or drafting a message) and explains optional parameters like shareClass for sharing with co-parents. It does not list explicit when-not-to-use scenarios, but the context is sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the description does not need to repeat that. It adds valuable behavioral context: 'Fetched LIVE from OFW, so the counts are current.' This goes beyond the annotation by explaining the data freshness.
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 three concise sentences, each adding value. The first sentence states the core purpose, the second adds behavioral detail, and the third clarifies what is not returned. No wasted words.
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?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It explains the action, the output (folder IDs and counts), the distinction from message content, and the live nature of the data.
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?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter details, and it correctly focuses on the tool's purpose and output.
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?
The description clearly states the verb 'List', the resource 'OurFamilyWizard message folders', and specifies that it returns folder IDs and unread counts. It distinguishes itself from sibling tools like ofw_list_messages by explicitly noting that it does not return message content.
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?
The description provides a clear usage hint: 'Returns folder IDs needed to call ofw_list_messages', implying the tool is a prerequisite. It also warns that it does not return message content, preventing misuse. However, it does not explicitly list when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations (only readOnlyHint: false) by disclosing that replacing a draft creates a new one and deletes the old, that response.id will be a new ID, that replyToId may be rewritten, that field preservation includes warnings, and that safety checks refuse write if draft changed. The annotation readOnlyHint: false is consistent with this mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long but structured with sections (FIELD PRESERVATION, SAFETY, etc.) and front-loads key behavior. However, it could be more concise; some details like 'the change is documented in a transparency NOTE' are verbose. For a complex tool with 8 params, the length is justified but slightly excessive.
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?
Despite lacking an output schema, the description effectively explains what the response contains (new id, warnings, serverBody for conflicts, revision). It covers all major behavioral aspects: replacement mechanism, field preservation, conflict detection, attachment handling, and threading. This is comprehensive for the tool's complexity.
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%, but the description adds significant meaning beyond parameter descriptions. It explains the effect of messageId (creates new draft, deletes old), force (overwrites conflict), expectedRevision (checks against local cache), and replyToId (may be normalized). These details guide correct usage beyond what the schema alone provides.
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?
The description clearly states the tool saves a message as a draft in OurFamilyWizard, with specific verb ('save') and resource ('draft'). It distinguishes from siblings like ofw_send_message (sending) and ofw_delete_draft (deleting) by focusing on saving a draft.
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?
The description explains when to use the tool (saving new drafts, replacing existing ones with messageId, attaching files) and provides important context such as conflict detection and the effect of force. It implicitly distinguishes from other tools, but lacks explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly discloses side effect of updating last-seen status, which annotations (readOnlyHint=false) only hint at. This adds critical behavioral context.
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?
Two sentences, front-loaded with purpose, behavioral note in second sentence. No wasted words.
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 zero-parameter tool with no output schema, the description adequately states return content and side effect, making it fully actionable.
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?
No parameters exist, so no parameter information is needed. The description properly omits any parameter discussion.
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?
Description clearly states the tool retrieves a dashboard summary with specific items (unread count, events, expenses), distinguishing it from sibling tools that target individual data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for a general overview but does not explicitly differentiate from siblings or provide when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits beyond the destructiveHint annotation: draft deletion after sending, potential rewriting of replyToId, and post-send cache population. No contradictions with annotations.
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?
The description is relatively long (150 words) but well-structured, starting with the core purpose then detailing each execution mode. Every sentence adds value, though it could be slightly more concise without losing clarity.
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?
Given 7 parameters, multiple modes, and no output schema, the description adequately covers requirements, side effects, and constraints. It even mentions a note in the response for replyToId rewrite. It could briefly describe the response structure, but overall it is complete enough for correct invocation.
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?
Adds significant meaning beyond the schema: explains the override behavior of messageId/draftId, the legacy draftId constraint, the replyToId rewrite, and the source of myFileIDs (from ofw_upload_attachment). Even though schema coverage is 100%, the description provides essential context for correct usage.
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?
The description clearly states the tool sends a message via OurFamilyWizard, distinguishes between sending a draft versus a fresh message, and mentions attachment handling. This differentiates it from sibling tools like ofw_save_draft and ofw_delete_draft.
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?
Provides explicit guidance on when to use messageId/draftId to send a draft versus providing subject/body/recipientIds for a fresh message, and how to attach files. However, it lacks explicit 'when not to use' statements or direct comparisons to sibling tools like ofw_save_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give destructiveHint: true. Description details the safety mechanism (re-read and refuse on change), local cache removal, and behavior of force parameter. No contradictions.
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?
Two sentences: first states the core action, second elaborates behavior. No fluff, front-loaded, each word contributes meaning.
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 tool with 3 parameters, no output schema, the description covers concurrency, safety, force option, and cache side effect. Comprehensive and sufficient for correct invocation.
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 covers all 3 parameters with descriptions (100% coverage). The description reinforces the meaning of expectedRevision and force, explaining their interplay, adding workflow context beyond bare 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?
Description clearly states 'Delete a draft message from OurFamilyWizard. Also removes the draft from the local cache.' It identifies the specific verb and resource, distinguishing it from siblings like ofw_save_draft and ofw_list_drafts.
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?
Provides guidance on when to use: deletion of drafts. Explains the re-read-and-refuse logic, expectedRevision, and force:true. Does not explicitly name alternatives like ofw_save_draft for modifications, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: fetching an unread INBOX message marks it read and stamps a 'First Viewed' time visible to the co-parent, which is irreversible. It also explains caching, draft behavior, and the effect of allowMarkRead. No contradiction with annotations (readOnlyHint: false).
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?
The description is moderately sized and front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise. It remains clear and well-structured.
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?
Given no output schema, the description adequately explains return values (folder, fromUser, sentAt, etc.) for different scenarios (draft vs inbox). It covers all important aspects for an agent to use the tool correctly.
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?
The description adds significant meaning beyond the schema, explaining that messageId accepts draft IDs, default behavior of allowMarkRead, and the server-wide ceiling. With 100% schema coverage, the description still enhances understanding.
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?
The description clearly states 'Get a single OurFamilyWizard message OR draft by ID.' This verb+resource definition is specific and distinguishes from sibling tools like ofw_list_messages or ofw_list_drafts.
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?
The description provides explicit guidance on when to use the tool, including handling of drafts, unread messages, and the allowMarkRead parameter. However, it does not explicitly mention when not to use it or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: it is a live call that may mutate state (marking messages as read via allowMarkRead, irreversible and co-parent-visible). It explains the verification logic and the meaning of the `complete` flag. This exceeds the annotation's false readOnlyHint by providing concrete details.
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?
The description is comprehensive and front-loaded with purpose, but it is relatively long. However, every sentence adds valuable information without redundancy, so its length is justified. Could be slightly more concise, but it remains efficient.
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?
Given no output schema, the description adequately explains return fields: state, sentAt, viewedAt, sentMessageId, and the top-level `complete` flag with its condition. It also clarifies edge cases (e.g., draftKeys resolving after sent). This covers all necessary behavioral context for an AI agent.
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?
Schema description coverage is 100%, and the description adds significant meaning beyond schema: it explains the stable identity of draftKeys, why they are needed (OFW creates new IDs on edit), and how they resolve to states. It also clarifies the default behavior of includeDraftInventory and the implications of allowMarkRead.
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?
The description clearly states the tool's purpose: 'ONE live call that answers "where does everything stand?"' and specifies it returns the full current draft inventory verified against OurFamilyWizard, distinguishing it from session memory or cached reads. It also explains the behavior with optional parameters like ids and draftKeys.
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?
The description provides clear usage context: 'This is the call that should back any status summary about drafts or specific messages — never session memory, and never a cached read alone.' It also explains when to use draftKeys and the allowMarkRead parameter. However, it does not explicitly contrast with sibling tools like ofw_list_drafts or ofw_get_message, which would strengthen the guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: reads from local cache, returns a 'complete' flag, and refusal with UNVERIFIED_EMPTY when cache is not fresh. Explains autoRefresh side effect, aligning with readOnlyHint=false annotation.
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?
Four-sentence paragraph is front-loaded with purpose, every sentence adds value, no wasted words.
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?
Even without an output schema, the description explains the 'complete' return field and special refusal result. All necessary details for using the tool are present.
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?
Schema coverage is 100%, and the description adds significant context for autoRefresh, including default behavior and cost implications, exceeding raw schema descriptions.
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?
Clearly states the tool lists sent messages that are unread by recipients, with specific verb and resource. Distinguishes from sibling tools like ofw_list_messages by specifying unread sent messages and local cache usage.
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?
Provides guidance on using autoRefresh to avoid refusal, explaining when it's needed. Does not explicitly contrast with alternatives, but the tool name and context imply its specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all behavioral traits beyond the annotations: it explains the inline delivery ladder, disk saving behavior, no-op on re-download, mime type normalization, and forced inline on hosted deployments. Annotations only indicate readOnlyHint=false, so the description fully covers the mutation and side effects.
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?
The description is front-loaded with the main purpose and each sentence adds value. However, it is lengthy and could be slightly more concise; still, the complexity of the tool justifies the detail.
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 tool with 7 parameters and no output schema, the description fully covers all aspects: behavior, response structure (meta block, extracted content), parameter defaults, edge cases, and context from sibling tools. It is complete and leaves no gaps.
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?
All 7 parameters are described in the schema (100% coverage), but the description adds significant meaning: e.g., the ladder for inline delivery, default extract behavior, relationship between inline and env var, and edge cases like force being ignored when inline:true. This greatly enriches understanding beyond 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?
The description clearly states the tool downloads an OFW message attachment by fileId and returns readable content. It specifies the inline delivery ladder for different file types, distinguishing it from sibling tools like ofw_get_message which provides the fileId but not the download.
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?
Explicit guidance on when to use inline vs disk mode, the OFW_INLINE_ATTACHMENTS env var, and the source of fileId (from ofw_get_message). Also explains when to set extract, force, and saveTo, and notes edge cases like hosted deployments where disk mode is unavailable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the readOnlyHint annotation: every call re-checks the newest page first, budget-based pausing and resumption, local vs. hosted unbounded behavior, and the irreversible mark-as-read effect of fetchUnreadBodies. This fully informs the agent of side effects and operational constraints.
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?
The description is comprehensive but somewhat verbose for the complexity of the tool. Every sentence is meaningful and well-organized, but some lines could be tightened without losing clarity. Overall, it balances detail with readability.
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?
The description covers all essential aspects: return values (counts, unread list), budget/resume mechanism, deep parameter for backfilling, mark-as-read implications, and local vs. hosted differences. Missing only minor details like error handling, but the complexity is well-addressed.
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 the schema descriptions cover 100% of parameters, the tool description adds significant context: it explains the budget mechanism for maxRequests, the backfill logic for deep, the mark-as-read implication for fetchUnreadBodies, and the default behavior for folders. This enhances understanding beyond the schema alone.
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?
The description clearly states the tool syncs messages from OurFamilyWizard into a local cache and returns counts per folder and a list of unread inbox messages without fetched bodies. It is distinct from sibling tools like ofw_get_message (fetches a specific message) and ofw_list_messages (lists messages), making its purpose unambiguous.
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?
The description provides explicit guidance on when to use this tool versus alternatives (e.g., call ofw_get_message on unread messages not fetched). It explains the bounded and resumable sync behavior, how to handle done:false responses, and the effect of the deep parameter for backfilling. It also warns that done:false does not mean recent messages are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses costs ('one OFW request per folder plus one per messageId'), explains return fields (live state, revision hash comparison), clarifies that drafts edited in web app don't change timestamps, and warns about allowMarkRead marking messages read irreversibly. Annotations show readOnlyHint=false, which is consistent with the potential write effect of allowMarkRead=true. No contradiction.
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 a single dense paragraph but efficiently front-loads purpose and cost. Every sentence adds value, no redundancy. It reads naturally while packing in behavioral details. Ideal length for this complexity.
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?
Given no output schema and three parameters with edge cases, the description fully covers what the tool does, when to use it, costs, side effects, output fields, and distinguishes from similar tools. Leaves no obvious gaps.
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?
Schema coverage is 100%, but description adds significant meaning: for folders it explains default behavior when messageIds omitted; for messageIds it details which cached states can be probed without marking read; for allowMarkRead it explains the irreversible consequence and server ceiling. This goes well beyond the schema's enum descriptions.
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?
The description clearly states the tool's purpose: 'Cheaply confirm whether the local cache still matches OurFamilyWizard, WITHOUT running a full sync.' It specifies a use case ('draft X is still sitting unsent') and distinguishes from siblings like ofw_status and full sync.
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?
Explicit guidance: 'Use this before asserting anything about current state' and 'For draftKeys, or a full live draft inventory, use ofw_status.' Also explains when not to use (if mark read side effect is undesirable) and provides alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ofw-mcp MCP server](https://glama.ai/mcp/servers/chrischall/ofw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/ofw-mcp)

Score Badge

Copy to your README.md:

[![ofw-mcp MCP server](https://glama.ai/mcp/servers/chrischall/ofw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/ofw-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/ofw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server