get_summary

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains what the tool returns (summary of expenses, income, net balance) and mentions 'optional category breakdown,' but it does not disclose aggregation semantics (e.g., whether results are grouped by month, whether date filters are inclusive, what happens with no filters - does it return all-time data?). For a read/query tool with zero annotation coverage, some of this is acceptable, but behavioral details like inclusive date boundaries and default scope are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear one-sentence summary, followed by a bulleted parameter list. This is well-structured. However, the parameter documentation is somewhat verbose for a read tool - each parameter gets its own line even though the schema already lists them. Given zero schema coverage, this duplication is justified, but the line-by-line format could be tightened. It earns its place but isn't maximally crisp.

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

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

The tool has 6 optional parameters with zero schema coverage, making it a fairly complex/ambiguous surface. The description documents every parameter with format and semantics. It has an output schema, so return-value structure needn't be explained. The main gap is not describing the default behavior with no filters (does it summarize all history?) and the aggregation granularity. But given the output schema exists and params are fully documented, the description is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema provides no parameter descriptions, so the tool description must carry the full load. It does: each of the 6 parameters is explained with format hints (YYYY-MM, YYYY-MM-DD), type hints (integer, boolean), and semantic meaning (filter by month, category from list_categories, transaction type). The by_category flag is explained as including a detailed category breakdown. This fully compensates for the zero schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Get a summary of expenses, income, and net balance with flexible filtering and optional category breakdown.' This is a specific verb (get) + resource (summary) + scope (expenses/income/net balance with filtering). It distinguishes from siblings like get_transactions (which returns itemized records) and spending_trends (which shows patterns over time) by focusing on aggregated summary values.

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

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

The description lists all available filters (month, date range, category, type, by_category) which gives clear context for when to use this tool. However, it does not explicitly state when NOT to use it or name alternatives (e.g., when to use get_transactions instead of get_summary, or when to use spending_trends). The sibling tools are discoverable, but no exclusions or alternatives are named.

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