Skip to main content
Glama

Bradescard MCP

by io.github.mcp-dir

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. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by detailing the return data (quantity, value, expenses, etc.) and bulk execution capability, which are not in annotations.

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

Conciseness4/5

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

Description is concise: two sentences in first paragraph, one in second. It front-loads the main purpose and key detail. However, the bulk support sentence could be integrated better, but no unnecessary text.

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?

Given no output schema, description partially explains return fields but omits pagination parameters. It mentions bulk support. However, for a tool with 4 parameters (0% schema coverage), more detail on page/page_size would be expected. Adequate but not comprehensive.

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

Parameters2/5

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

Input schema has 0% description coverage. Description explains investment_id (from previous tool) and investment_ids (for bulk), but does not mention page and page_size parameters at all. Thus, half the parameters lack any semantic help.

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 it returns movement history for an investment position with specific transaction types (BUY/SELL/etc.) and fields. It distinguishes itself from openfinance_list_investments by advising to use that tool first to get the 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?

Description explicitly says 'Use after openfinance_list_investments to get the investment_id', providing a clear prerequisite. It also mentions bulk support for batched execution. However, it does not explicitly state when not to use or compare with other siblings.

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

All Bradescard MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools are highly distinct, targeting different resources (accounts, transactions, bills, loans, investments, connections). However, openfinance_list_transactions and openfinance_list_transactions_by_item both return transaction data with different scopes, which could cause misselection. Also openfinance_get_item_status vs openfinance_provider_status are distinct but similar in name.

Naming Consistency5/5

The openfinance_* tools follow a consistent verb_noun pattern (list_accounts, get_credit_card_bill, force_sync). Generic tools (authenticate, connect, marketplace) are also clearly named and consistent within their own domain. No mixed conventions or chaotic naming.

Tool Count4/5

At 25 tools, the server is on the heavier side (borderline of the 16-25 range) but each tool serves a clear purpose in the open finance domain, covering multiple resource types and auxiliary functions like marketplace and status. A slight trim could be made (e.g., merging some list/get pairs), but it's not excessive.

Completeness4/5

The server covers the full read lifecycle for accounts, transactions, bills, loans, and investments, plus connection management (list, disconnect, force sync) and category updates. Minor gaps like lack of direct deletion for financial records are acceptable since those are not typical operations. The generic tools (marketplace, auth, version) round out the toolkit.

Resources