List accounts in a YNAB plan to view their ID, name, type, budget status, and balance. Set include_closed to true to also show closed accounts.
List accounts in a plan: id, name, type, on-budget flag, balance. Closed accounts are hidden unless include_closed=true.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | ||
| include_closed | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already covers the safety profile. The description adds meaningful behavioral context beyond the annotation by disclosing that closed accounts are hidden unless include_closed=true, and by specifying the returned fields. It does not cover plan-null behavior or pagination, but the extra context justifies a strong score.
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 entire description is one tightly structured sentence: action, field list, then the conditional filter behavior. Every phrase contributes information, with the core purpose front-loaded and no filler.
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 two-parameter list tool with an output schema and a read-only annotation, the description covers the essential fields and the key filtering behavior. The main gap is the ambiguous 'plan' parameter defaulting to null, which leaves the agent unsure whether omitting it lists all plans or requires a plan identifier.
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?
With 0% schema description coverage, the description carries the burden of explaining both parameters. It clearly explains include_closed via the 'unless include_closed=true' clause, but 'plan' is only glossed as 'in a plan' without clarifying the default null semantics (e.g., all plans vs current plan). Compensation is partial.
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 opens with the specific verb 'List' and the resource 'accounts', and enumerates the exact fields returned (id, name, type, on-budget flag, balance). It is immediately distinguishable from siblings like list_plans, list_payees, and list_categories, which target different resources.
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 intended use case is implied by the resource and the 'in a plan' qualifier, but no explicit guidance is given for when to choose this over alternatives. There are no exclusions or comparisons to siblings, so the agent must rely on the name to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.