List check deposits for an account, including status, holds, and MICR payer details, with optional filtering by account.
List check deposits, optionally filtered by account (status, holds, MICR payer details).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items per page (1-100) | |
| cursor | No | Opaque cursor from the previous page's `cursor` field | |
| account_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'List' conveys a non-mutating read, and the parenthetical hints at output concepts such as status, holds, and MICR payer details. However, pagination/cursor behavior is not disclosed, and the parenthetical could mislead by suggesting filter options that do not exist in the schema.
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 one short, front-loaded sentence with a clear verb and resource, and there is no filler. The parenthetical compresses three pieces of information into an ambiguous fragment, reducing structural clarity. It is concise but not as clean or unambiguous as it could be.
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 optional-filter list call, the core action and account filter are present, and limit/cursor are described in the schema. There is no output schema, and the description only hints at returned fields without explaining that the result is a page or how to follow the cursor. It is minimally sufficient but leaves response-shape and sibling-selection details to inference.
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 coverage is 67% because limit and cursor already have descriptions, leaving only account_id undocumented. The description adds that the optional filter is by account, which maps to account_id, but it does not clarify the account_id format or resolve the ambiguity around status/holds/MICR details. This meets the schema baseline but does not exceed it.
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 states a concrete verb and resource: 'List check deposits', with an optional account filter, which distinguishes it from the singular lemma_get_check_deposit and other list family tools. The parenthetical '(status, holds, MICR payer details)' is ambiguous—it could mean returned fields or additional filters—so the purpose is not perfectly crisp.
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 explicit when-to-use guidance is provided, and no alternative tools are named. The description implies a list use case and an optional account filter, but it does not say when to prefer lemma_get_check_deposit instead or how this list relates to other list endpoints. The agent must infer selection from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.