Skip to main content
Glama
dacmail

indexa-capital-mcp-server

by dacmail

Get Indexa account transactions

indexa_get_transactions
Read-onlyIdempotent

Retrieve transaction history for your Indexa account, including contributions, withdrawals, fund subscriptions, redemptions, dividends, and fees, with optional date filtering.

Instructions

Retrieve the transaction history for an Indexa account: contributions (aportaciones), withdrawals (retiradas), fund subscriptions and redemptions, dividend reinvestments, fees charged, etc.

Use this for questions about money in/out of the account or specific operations on a date.

Args:

  • account_number (string): Indexa account ID

  • date_from (string, optional): Lower date bound (YYYY-MM-DD)

  • date_to (string, optional): Upper date bound (YYYY-MM-DD)

  • limit (number, default 50, max 500): Maximum transactions to return

  • offset (number, default 0): Pagination offset

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: For JSON format, an array of transaction objects. The exact shape is not fully published in the Indexa RAML, but transactions typically include: { "date": "YYYY-MM-DD", "amount": number, // EUR; positive = into account "type": string, // e.g. "contribution", "subscription", "redemption", "fee" "description": string, "instrument"?: { "name": string, "identifier": string // ISIN } }

Examples:

  • Use when: "How much have I contributed to Indexa this year?"

  • Use when: "Show my last 20 movements on account NK1NUTP1"

  • Use when: "Did I get charged fees in March?"

Error handling:

  • 404: endpoint not available for this account type or status.

  • 401/403: token invalid.

Note: Date filtering and pagination are applied client-side after the API responds. For very active accounts with many years of history, narrow the date_from / date_to window to keep responses fast and within limits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_numberYesIndexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'.
date_fromNoDate in YYYY-MM-DD format. Example: '2024-01-15'.
date_toNoDate in YYYY-MM-DD format. Example: '2024-01-15'.
limitNoMaximum transactions to return after date filtering.
offsetNoNumber of transactions to skip after date filtering.
response_formatNoOutput format: 'markdown' for human-readable summary or 'json' for full structured data.markdown
Behavior4/5

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

Annotations already declare the tool is read-only and idempotent. The description adds behavioral details: client-side date filtering and pagination, error codes (404, 401/403), and a note about performance. No contradiction with 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?

The description is well-structured with sections (overview, Args, Returns, Examples, Error handling, Note). It is appropriately detailed without being verbose, though some sections could be slightly more concise.

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

Completeness5/5

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

Given the complexity (6 parameters, no output schema), the description includes a typical return object shape and performance recommendations. It covers all necessary aspects for an AI agent to use the tool effectively.

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

Parameters4/5

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

Schema coverage is 100%, and the description adds value with explanations for each parameter (e.g., account_number as 'Indexa account ID', format for dates, default/max for limit). It also notes the client-side filtering behavior, which is not in schema.

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?

The description clearly states the tool retrieves transaction history for an Indexa account, listing specific transaction types (contributions, withdrawals, fund subscriptions, etc.). It distinguishes itself from sibling tools by focusing on transactions, not account details or portfolio.

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?

The description provides explicit when-to-use guidance with examples (e.g., 'How much have I contributed this year?') and lists scenarios. It does not explicitly state when not to use, but the context is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dacmail/indexa-capital-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server