Skip to main content
Glama
OurFamilyWizard MCP

OurFamilyWizard MCP

by chrischall

ofw_list_expenses

Read-only

List OurFamilyWizard expenses using 1-based page and size parameters; continue with nextPage from the response when more records exist.

Instructions

List OurFamilyWizard expenses. OFW pages this endpoint with 1-based page/size parameters; its older start/max parameters are ignored and repeatedly return page 1. The response leads with hasMore and nextPage (null when exhausted) before the records. Continue by passing nextPage.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number (default 1). To continue, pass the nextPage returned by the previous response.
sizeNoRequested page size (default 20). OFW may cap or normalize this value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.20.0
    • removedInput schema / properties / max
      Removed value: -{
      -  "description": "Max results (default 20)",
      -  "maximum": 9007199254740991,
      -  "minimum": 1,
      -  "type": "integer"
      -}
    • addedInput schema / properties / page
      Added value: +{
      +  "description": "1-based page number (default 1). To continue, pass the nextPage returned by the previous response.",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / size
      Added value: +{
      +  "description": "Requested page size (default 20). OFW may cap or normalize this value.",
      +  "maximum": 100,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • removedInput schema / properties / start
      Removed value: -{
      -  "description": "Start offset, 0-based (default 0). To continue a listing, pass the `nextStart` from the previous response.",
      -  "maximum": 9007199254740991,
      -  "minimum": 0,
      -  "type": "integer"
      -}
  2. 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"
  3. Changed1 schema field changedv2.14.0
    • changedInput schema / properties / start / description
      Previous value: -"Start offset (default 0)"New value: +"Start offset, 0-based (default 0). To continue a listing, pass the `nextStart` from the previous response."
  4. First observedv2.8.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, setting a lower bar. The description adds valuable non-obvious behavior: pagination quirks (old start/max ignored, always page 1) and response structure leading with hasMore and nextPage. It doesn't cover auth or rate limits, but for a read operation, this is strong added context.

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?

Three sentences, each earning its place: purpose, pagination caveat, and continuation instruction. Front-loaded with what the tool does. Slightly dense with technical details, but efficient and no 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?

With annotations covering read-only and open-world behavior, and no output schema, the description provides the critical missing piece: pagination mechanics and continuation. It doesn't describe return fields beyond nextPage/hasMore, but that's reasonable given no output schema and the focus on 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that the older start/max parameters are ignored and that continuation should use nextPage from the response. This directly informs parameter usage beyond the schema's formal definitions.

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?

States a clear verb+resource: 'List OurFamilyWizard expenses.' An agent can distinguish it from siblings like ofw_get_expense_totals (totals vs. list) and ofw_create_expense (create vs. list). No explicit sibling naming, but the verb+resource is specific enough to differentiate from most.

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 when to use pagination by explaining nextPage continuation, which is useful guidance. However, it doesn't explicitly state when to use this tool vs. alternatives like ofw_get_expense_totals or mention any exclusions. Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.