List schedules

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

The readOnlyHint annotation already declares this is a read-only operation, so the bar for behavioral disclosure is lower. The description adds that it returns name, next date, and amount fields for recurring schedules, providing useful context about what kind of list is returned. The include_completed parameter implies completed schedules exist, which is a behavioral nuance the description hints at but doesn't elaborate on. No contradiction 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.

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

The description is a single efficient sentence that front-loads the core purpose. Zero wasted words. The parenthetical enumerating returned fields (name, next date, amount) is value-add and compact. Not quite a 5 because it leaves the parameter semantics unanswered, but structurally clean.

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?

For a simple list tool with readOnlyHint and one optional parameter, the bar is moderate. The description covers the return content (name, next date, amount) but says nothing about the include_completed parameter, what completed schedules are, ordering, or pagination. With 0% schema coverage and the parameter left fully unexplained, the tool description leaves a real gap in agent understanding.

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%, so the schema provides NO explanation for the include_completed parameter. The description doesn't mention include_completed at all, meaning an agent would have to infer from the name that it controls whether finished schedules appear in results. Since coverage is low and the description fails to compensate, this scores below baseline.

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 'Recurring schedules configured in Actual (name, next date, amount)' states a clear verb-resource pair and gives the resource scope (schedules) plus key fields. However, it doesn't distinguish from siblings beyond being a natural extension of the get_* list family. The parenthetical fields add useful specificity, making the purpose clear, but there's no explicit differentiation from sibling list tools like get_net_worth or get_rules.

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 on when to use this tool vs alternatives is provided. With 10 sibling get_* tools, an agent gets no indication of when schedules (recurring future transactions) would be preferred over get_transactions or get_rules. There's implied context that this is for recurring schedules, but no explicit when/when-not statements or alternative tool references.

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