get_dashboard_stats

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

With no annotations provided, the description must carry the behavioral disclosure burden. It does communicate a read-only aggregate and names the output categories, but it remains silent on whether the optional lang parameter affects results, the time scope of bills, or whether 'amounts owed and owing' are totals or breakdowns. This is partial disclosure, not complete.

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?

One concise sentence that front-loads the main purpose and lists the key output fields. Every word earns its place, and there is no redundant or filler text.

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 description covers the basic return categories but omits any explanation of the optional lang parameter, the assumed scope of bills, and the return shape. Because there is no output schema and no annotations, these missing details leave the agent with incomplete information to call the tool correctly and interpret its response.

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?

The only parameter, lang, appears in the schema with no description and is not mentioned in the tool description. Since schema description coverage is 0%, the description fails to clarify whether lang is a language code, locale, or something else, leaving the agent to guess. This is a critical gap in an otherwise simple tool.

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 uses a specific verb ('Get'), names the resource ('SplitBill dashboard totals'), and enumerates exact contents (bill count, amounts owed and owing). This clearly distinguishes it from sibling tools like list_bills or get_bill, which are about individual bills rather than aggregated totals.

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?

No guidance is provided on when to use this tool versus siblings such as list_bills or get_bill. The description implies a dashboard context but does not state whether this tool aggregates across all bills, whether it requires authentication, or how it relates to the other bill/stat endpoints.

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