Retrieve bank accounts for a specified entity, showing balances in cents with dollar annotations. Supports pagination using cursor and limit.
List Lemma bank accounts for an entity, with balances (cents; *_dollars annotated).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items per page (1-100) | |
| cursor | No | Opaque cursor from the previous page's `cursor` field | |
| entity_id | Yes | Required -- accounts are listed per entity |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose a meaningful output trait: balances are in cents and *_dollars fields are annotated. However, it does not mention pagination behavior, ordering, authentication requirements, or whether the list is read-only beyond what the verb 'List' implies.
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, front-loaded sentence that immediately identifies the action and resource, then appends a valuable parenthetical about balance representation. There is no wasted wording or repetitive schema content.
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 full schema coverage, the description is serviceable: it names the required entity scoping and the distinctive balance format. But with no output schema and no annotations, it leaves gaps around pagination, response shape, and how this tool relates to the many sibling account-related tools.
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 input schema covers all parameters with descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond naming the entity relationship, and it does not elaborate on limit or cursor semantics beyond what the schema already provides.
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 the action (List), the resource (Lemma bank accounts), and the scope (for an entity). It also adds a useful output detail about balances and units. However, it does not explicitly distinguish this from the closely named sibling lemma_list_external_accounts or lemma_get_bank_account, so it stops short of full differentiation.
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 gives no guidance on when to choose this tool over alternatives such as lemma_list_external_accounts or lemma_get_bank_account. It only restates the entity constraint from the schema, with no mention of exclusions, pagination usage, or situations where a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.