Lists treasury bank accounts from Holded with cursor-based pagination, returning page results and a next cursor for fetching subsequent pages.
List treasury bank accounts (Holded API v2, official endpoint). Cursor-paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items per page | |
| cursor | No | Cursor from a previous response nextCursor |
Changes observed during successful MCP inspections.
v2.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the key behavioral trait — cursor pagination — which tells the agent to loop on cursors, but says nothing about ordering, default page size, permissions, or whether it returns all accounts regardless of filters.
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?
Two short sentences, front-loaded with the resource and the pagination model. Slightly over-leveraged on the "official endpoint" parenthetical, which carries little selection value for an agent.
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?
There is no output schema and no annotations, so the description is the only place to learn return shape and list semantics. It covers pagination but omits what a record contains and whether the list is complete versus filtered — adequate but with clear gaps for a list tool with zero structured support.
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 100% and both parameters (limit, cursor) are documented inline, so the baseline is 3. The description's "cursor-paginated" phrasing reinforces the schema but adds no format, default, or max values beyond 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?
Specific verb + resource ("List treasury bank accounts") so an agent knows this is a read/list operation over bank accounts. It does not distinguish itself from nearby siblings such as list_treasuries or list_bank_movements, though the resource name is specific enough to be actionable.
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 versus list_treasuries, list_bank_movements, or get_bank_account for a single record. The parenthetical about the API version/endpoint adds provenance but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.