Skip to main content
Glama

openfinance_list_investment_transactions

Read-onlyIdempotent

Returns the movement history for a specific investment position: BUY / SELL / TAX / INTEREST / AMORTIZATION / TRANSFER. Each row carries quantity, value, amount, netAmount, agreedRate (treasury), brokerageNumber, and itemized expenses (brokerageFee, incomeTax, settlementFee, custodyFee, stockExchangeFee, etc.). Use after openfinance_list_investments to get the investment_id.

Bulk support: accepts investment_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
page_sizeNo
investment_idYes
investment_idsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added
  2. Removed
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context by detailing the nature of data (movement history, transaction types) and the fields returned. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines purpose and data fields, second gives usage guidance. No unnecessary words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes return values (transaction types and fields) but does not explain pagination behavior or output format. Without an output schema, the description should cover what to expect, which is partially done.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It explains investment_id and investment_ids (bulk) but does not mention page or page_size parameters. Missing pagination semantics, but provides some context for the main parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns movement history for a specific investment position, listing transaction types (BUY/SELL etc.) and fields (quantity, value, amounts, expenses). Distinguished from siblings like openfinance_list_investments and openfinance_list_transactions by specifying 'investment transactions' and referencing investment_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use after openfinance_list_investments to obtain investment_id, and mentions bulk support for multiple investment_ids. Does not explicitly state when not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose. The Open Finance tools are granular (e.g., list vs get vs force_sync for different resources), and the marketplace, authentication, and utility tools do not overlap. No two tools could be easily confused.

Naming Consistency4/5

The Open Finance tools consistently use the 'openfinance_' prefix followed by a verb_noun pattern (e.g., list_accounts, get_balance). Other tools (authenticate, connect, marketplace) use simple verb names, which is a minor deviation but still clear and predictable.

Tool Count4/5

25 tools is on the higher end, but the server covers a broad domain (marketplace + comprehensive Open Finance operations). Each tool serves a specific function, and the count is justified by the depth of functionality.

Completeness5/5

The toolset provides full lifecycle coverage for the Open Finance domain: list, get, sync, update, transactions, categories, investments, loans, credit cards, and connections. The marketplace tool is also feature-rich. No obvious gaps for the intended purpose.