Retrieve paginated investment holdings with optional type filtering to monitor your portfolio positions.
Investimentos do Item; página numerada, tamanho entre 1 e 500.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| type | No | ||
| page_size | No |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| data | No | ||
| meta | Yes | ||
| tool | Yes | ||
| error | No | ||
| warnings | Yes | ||
| pagination | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly and non-destructive behavior. The description adds only the pagination traits (numbered page, page size between 1 and 500), which is useful but sparse. It does not disclose behavior like default ordering, result size limits beyond 500, or how the optional type filter affects results.
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 extremely compact and has no filler, with the core resource named first. It sacrifices substance for brevity, but as a concise statement it is well-structured and easy to parse.
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?
Despite having an output schema, the description is not complete enough for correct invocation: it leaves the `type` parameter unexplained, the identity of 'Item' unclear, and the relationship to sibling investment tools unstated. An agent would need to infer too much from the schema alone.
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 must compensate for the schema's lack of documentation. It adds a page_size constraint (1-500) not present in the schema, but it completely ignores the `type` filter parameter and its enum values, and only vaguely maps 'página numerada' to `page`.
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 identifies the resource as investments and implies a listing operation via the tool name, but the phrase 'Investimentos do Item' is ambiguous about what 'Item' refers to. It also does not differentiate this from close siblings like list_investment_transactions or get_investment_portfolio.
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 is given about when to use this tool versus list_investment_transactions, get_investment_portfolio, or get_investment. The optional type filter is not mentioned as a way to narrow results, and no exclusions or alternative conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.