Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@indexa-capital-mcp-server how are my investments doing?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP de solo lectura para monitorizar tus inversiones en Indexa Capital desde Claude (Desktop, Code, web).
Implementa el subconjunto de lectura de la API REST v1.6 de Indexa:
Tool MCP | Endpoint | Para qué sirve |
| varios | Resumen agregado de todas tus cuentas en una sola llamada |
|
| Lista de cuentas y datos del usuario |
|
| Perfil de la cuenta, riesgo, titulares |
|
| Composición actual: valor, fondos, ISIN, P/L |
|
| Serie histórica de rentabilidad y benchmark |
|
| Movimientos: aportaciones, suscripciones, retiradas |
|
| Comisiones de gestión por trimestre |
Nota de seguridad: este servidor no implementa ningún endpoint de escritura (no puede mover dinero, abrir cuentas, ni modificar tu perfil). Si en el futuro quieres añadir aportaciones programadas o transferencias, requiere un fork explícito.
Node.js 18 o superior
Una cuenta en Indexa Capital
Un token de API personal (instrucciones más abajo)
Related MCP server: eToro Portfolio Connector
No hace falta clonar ni compilar: el paquete incluye el código ya construido en dist/.
Instalación global (el binario queda en tu PATH de npm):
npm install -g indexa-capital-mcp-serverO ejecutarlo sin instalar globalmente (npx descarga el paquete cuando hace falta; -y evita el prompt de confirmación):
npx -y indexa-capital-mcp-servergit clone https://github.com/dacmail/indexa-capital-mcp-server.git
cd indexa-capital-mcp-server
npm install
npm run buildEntra en tu área privada de Indexa Capital.
Ve a Configuración de usuario → Aplicaciones.
Genera un token. Tendrá esta pinta: eyJ0eXAiOiJKV1Qi....
Guárdalo a buen recaudo: es personal, intransferible, y suficiente para acceder a todos los datos de tu cuenta.
Edita ~/Library/Application Support/Claude/claude_desktop_config.json y añade una de estas opciones.
Con npx (recomendado; no necesitas ruta al clon ni al global node_modules):
{
"mcpServers": {
"indexa-capital": {
"command": "npx",
"args": ["-y", "indexa-capital-mcp-server"],
"env": {
"INDEXA_API_TOKEN": "eyJ0eXAiOiJKV1Qi..."
}
}
}
}Si instalaste el paquete con npm install -g:
{
"mcpServers": {
"indexa-capital": {
"command": "indexa-capital-mcp-server",
"args": [],
"env": {
"INDEXA_API_TOKEN": "eyJ0eXAiOiJKV1Qi..."
}
}
}
}Si trabajas desde un clon local (tras npm run build):
{
"mcpServers": {
"indexa-capital": {
"command": "node",
"args": ["/ruta/absoluta/a/indexa-capital-mcp-server/dist/index.js"],
"env": {
"INDEXA_API_TOKEN": "eyJ0eXAiOiJKV1Qi..."
}
}
}
}Reinicia Claude Desktop. Verás las 7 tools disponibles bajo el icono del enchufe.
Con paquete publicado en npm (npx):
claude mcp add indexa-capital \
--env INDEXA_API_TOKEN=eyJ0eXAiOiJKV1Qi... \
-- npx -y indexa-capital-mcp-serverCon instalación global:
claude mcp add indexa-capital \
--env INDEXA_API_TOKEN=eyJ0eXAiOiJKV1Qi... \
-- indexa-capital-mcp-serverDesde un clon local:
claude mcp add indexa-capital \
--env INDEXA_API_TOKEN=eyJ0eXAiOiJKV1Qi... \
-- node /ruta/absoluta/a/indexa-capital-mcp-server/dist/index.jsUna vez conectado, puedes preguntarle a Claude cosas como:
"¿Cómo van mis inversiones en Indexa?" — usa indexa_portfolio_summary
"¿Qué fondos tengo en mi cartera de Indexa?" — usa indexa_get_portfolio
"¿Cuánto he ganado este año en mi plan de pensiones?" — usa indexa_get_performance con date_from
"Lista las aportaciones que hice en 2024" — usa indexa_get_transactions con filtro de fechas
"¿Cuánto me ha cobrado Indexa en comisiones desde que abrí la cuenta?" — usa indexa_get_fees
# Compilar
npm run build
# Test rápido del token
INDEXA_API_TOKEN=eyJ... node -e "
const axios = require('axios');
axios.get('https://api.indexacapital.com/users/me', {
headers: { 'X-AUTH-TOKEN': process.env.INDEXA_API_TOKEN }
}).then(r => console.log(JSON.stringify(r.data, null, 2)));
"
# Inspector MCP oficial
npx @modelcontextprotocol/inspector node dist/index.js(Recuerda exportar INDEXA_API_TOKEN antes de lanzar el inspector.)
src/
├── index.ts # Entry point, registro de tools
├── constants.ts # API URL, headers, límites
├── schemas/
│ └── common.ts # Schemas Zod compartidos
├── services/
│ ├── client.ts # Cliente Axios + manejo de errores
│ └── format.ts # Helpers de formato (Markdown/JSON/EUR)
└── tools/
├── get_me.ts
├── get_account.ts
├── get_portfolio.ts
├── get_performance.ts
├── get_transactions.ts
├── get_fees.ts
└── portfolio_summary.tsEl base URL es https://api.indexacapital.com.
La autenticación se hace con el header X-AUTH-TOKEN.
Los tokens generados desde el área privada no caducan, a diferencia de los tokens emitidos vía /auth/authenticate que duran ~16 h.
Los endpoints /portfolio, /performance, /transactions y /fees no aparecen en la documentación pública RAML pero están confirmados por el soporte oficial y por clientes existentes (Indexa-Dashboard, plantillas Google Sheets, integraciones de la suite Sure). Las interfaces TypeScript son intencionalmente permisivas (? opcional, [key: string]: unknown) por si la API evoluciona.
MIT.
Retrieve static information about a single Indexa account: product type (cartera de fondos / plan de pensiones), risk profile (1-10), holders, account status, funding state and currency.
This tool does NOT return the current portfolio value, holdings, or performance — for those use indexa_get_portfolio and indexa_get_performance.
Args:
account_number (string): Indexa account ID, obtained from indexa_get_me
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For JSON format, the raw response from GET /accounts/{account_number}: { "account_number": string, "account_type": "personal" | "company" | "minor", "type": "mutual" | "pension", "currency": string, // typically "EUR" "status": string, // "active", "pending-contract", etc. "funding": "total" | "partial" | "no", "profile": { "selected_risk": 1-10, // user-selected risk level "risk": { "tolerance": 1-10, // questionnaire-derived "capacity": 1-10, "total": 1-10 // = min(tolerance, capacity) }, "is_outdated": boolean, "needs_to_be_updated": boolean }, "holders": [...], // titulares con nombre y DNI "platform_code": string }
Examples:
Use when: "What's my risk profile on account NK1NUTP1?"
Use when: "Is my pension account active?"
Don't use when: The user wants the current portfolio value (use indexa_get_portfolio) or returns (use indexa_get_performance).
Error handling:
404: account_number does not exist or you don't have access to it.
401/403: token invalid or revoked.
| Name | Required | Description | Default |
|---|---|---|---|
| account_number | Yes | Indexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'. | |
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by specifying the static nature, listing return fields, and including error handling (404, 401/403), which are beyond the annotations.
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 well-structured with clear sections (purpose, exclusions, args, returns, examples, error handling). Each sentence adds value, and the main purpose is front-loaded.
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 no output schema, the description provides a detailed JSON response structure and covers error scenarios. With only 2 parameters and good annotations, the description is complete for effective tool usage.
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% with good descriptions, but the description further clarifies parameter usage (e.g., account_number origin, default response_format) and provides a full JSON response example that enriches understanding.
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 starts with a clear verb ('Retrieve') and resource ('static information about a single Indexa account'), lists specific fields, and explicitly distinguishes from sibling tools by stating what it does not return.
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?
Explicitly states when not to use (for portfolio value or performance) and names alternative tools (indexa_get_portfolio, indexa_get_performance). Also provides 'use when' examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the management fees charged by Indexa Capital on an account. Indexa bills quarterly, and this endpoint returns one record per quarter, including the asset base used, the net fee, VAT, the effective fee rate, and a link to the invoice PDF.
Args:
account_number (string): Indexa account ID
date_from (string, optional): Filter to quarters that end on or after this date (YYYY-MM-DD)
date_to (string, optional): Filter to quarters that start on or before this date (YYYY-MM-DD)
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For JSON format, an array of fee records: [ { "account_number": string, "date_from": "YYYY-MM-DD", // start of the billing quarter "date_to": "YYYY-MM-DD", // end of the billing quarter "fees": number, // net management fee in EUR "vat": number, // VAT applied in EUR "amount": number, // asset base used "average_fee": number, // effective fee rate (e.g. 1.95 = 1.95 bps avg) "document": { // invoice PDF metadata "showName": string, "show_name": string, "created_at": "YYYY-MM-DD HH:mm:ss" } } ]
The Markdown format computes total fees and total VAT for the filtered range.
Examples:
Use when: "How much did Indexa charge me in fees last year?"
Use when: "What's my effective fee rate on my pension account?"
Use when: "List all fee invoices since 2023"
Error handling:
404: account not found or no fees yet (e.g. very recently opened).
401/403: token invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| account_number | Yes | Indexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'. | |
| date_from | No | Date in YYYY-MM-DD format. Example: '2024-01-15'. | |
| date_to | No | Date in YYYY-MM-DD format. Example: '2024-01-15'. | |
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description details that it returns one record per quarter, includes asset base, net fee, VAT, effective fee rate, and invoice PDF link. Also explains error handling (404, 401/403) and date filtering logic.
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?
Well-structured with sections for description, args, returns, examples, and error handling. Somewhat verbose but all sentences contribute value; front-loading is effective.
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 no output schema, description fully documents return fields for JSON format, explains Markdown summary, and covers filtering behavior and error codes. Complete for an agent to use without ambiguity.
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% with good descriptions, but the description adds semantics like 'quarters that end on or after this date' for date_from and 'quarters that start on or before this date' for date_to, plus examples for account_number and response_format.
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?
Description clearly states 'Retrieve the management fees charged by Indexa Capital on an account' with specific verb and resource. Distinguishes from sibling tools like indexa_get_transactions or indexa_get_performance by focusing exclusively on fees.
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?
Provides concrete examples under 'Use when:' (e.g., 'How much did Indexa charge me in fees last year?') and explains the quarterly billing context. Does not explicitly exclude other tools but the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the authenticated user's profile and the list of all Indexa Capital accounts they own or have access to.
This is the entry point of the API: every other tool requires an account_number, and this tool is how you discover them. The token in INDEXA_API_TOKEN identifies the user, so no input is required.
Args:
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For JSON format, the raw response from GET /users/me: { "username": string, "email": string, "name"?: string, "surname"?: string, "document": string, "document_type": string, "roles": string[], "is_activated": boolean, "accounts": [ { "account_number": string, // e.g. "NK1NUTP1" — pass to other tools "status": string, // "active", "pending-contract", etc. "type": "mutual" | "pension" } ], "accounts_relations": [ { "account_number": string, "relation": "owner" | "auth" | "guest" } ] }
Examples:
Use when: User asks "what accounts do I have at Indexa?" or any question that mentions Indexa investments without specifying an account.
Use when: You need an account_number to call any other indexa_* tool.
Don't use when: The user already gave you an account_number.
Error handling:
401/403: token is invalid or revoked. Regenerate it in the Indexa private area at Configuración de usuario > Aplicaciones.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, open world. Description adds important behavioral context: token authenticity via INDEXA_API_TOKEN, detailed return structure, and error handling for 401/403. This goes beyond what annotations provide.
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?
Description is well-structured with sections (Args, Returns, Examples, Error handling) and front-loads the purpose. Slightly verbose with the JSON example but remains efficient overall.
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?
For a simple 1-parameter tool, the description covers everything: purpose, when to use, return structure (despite no output schema), error handling, and integration with sibling tools. No gaps identified.
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 covers the single parameter fully (response_format with enum and default). Description adds clarity that no input is required beyond the token, and explains the effect of choosing 'markdown' vs 'json'. Adequate but not exceptional beyond schema.
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 clearly states it retrieves the authenticated user's profile and list of accounts. It distinguishes itself from siblings by positioning itself as the entry point to discover account numbers needed for other tools.
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?
Provides explicit examples of when to use (user asks about accounts, need account_number) and when not to use (user already provided account_number). Also covers the prerequisite for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the historical performance series for an Indexa account, with optional date filtering and projection data.
Performance values are returned in base 100 — a value of 105 at index N means +5% cumulative return since the start of the series. Per Indexa support, returns between two points are computed as: 100 * (return[end] / return[start] - 1).
Args:
account_number (string): Indexa account ID
date_from (string, optional): Filter the series to start on or after this date (YYYY-MM-DD)
date_to (string, optional): Filter the series to end on or before this date (YYYY-MM-DD)
include_projections (boolean, default false): Whether to include best/worst/expected forward projections in the JSON output. These can be large; leave off unless explicitly needed.
response_format ('markdown' | 'json'): Output format (default: 'markdown')
The Markdown format computes and displays:
Cumulative return over the period
Annualised return (estimated from the date range)
Plan expected return (Indexa's own projection)
Benchmark comparison and alpha (if benchmark series is present)
A sampled subset of the curve as a table (~8 points)
Returns: For JSON format, the structure is: { "plan_expected_return": number, // e.g. 0.0384 = +3.84%/year expected "performance": { "period": ["YYYY-MM-DD", ...], // dates "return": [number, ...], // base-100 actual return series "benchmark"?: [number, ...], // base-100 benchmark series "best"?: [number, ...], // best-case projection (if requested) "worst"?: [number, ...], // worst-case projection "expected"?: [number, ...] // expected projection } }
Examples:
Use when: "What's my YTD return on Indexa?" -> date_from = first day of year
Use when: "How has my account performed since I opened it?" -> no dates
Use when: "Compare my returns to the benchmark"
Don't use when: The user wants the current value (use indexa_get_portfolio) or transaction history (use indexa_get_transactions).
Error handling:
404: account not found or no performance data yet (e.g. just opened).
401/403: token invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| account_number | Yes | Indexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'. | |
| date_from | No | Lower bound for the returned series (YYYY-MM-DD). Omit for full history. | |
| date_to | No | Upper bound for the returned series (YYYY-MM-DD). Omit for latest available. | |
| include_projections | No | Include best/worst/expected projection arrays in the JSON output. These can be very large; default false to keep responses small. | |
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds important behavioral details beyond annotations: base-100 return interpretation, formula for returns between two points, and warning that projections can be large. No contradictions.
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?
Description is relatively long but well-structured with sections for purpose, args, returns, examples, and error handling. It is front-loaded with key info. Every sentence serves a purpose; no wasted words. Slightly verbose but necessary for a complex tool.
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 no output schema, description provides detailed return format for both markdown and JSON, including field descriptions and types. Covers error codes and scenarios. For a 5-parameter tool with optional projections and output format choice, this is very thorough.
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 description coverage is 100%, so baseline is 3. Description adds significant value for each parameter: account_number references schema from another tool, dates specify YYYY-MM-DD, include_projections warns about size, response_format explains output differences. This goes beyond what schema provides.
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?
Description clearly states it retrieves historical performance series for an Indexa account, with specific verb 'Retrieve' and resource 'performance series'. It distinguishes from siblings by providing examples and explicitly warning not to use for current value (use indexa_get_portfolio) or transactions (use indexa_get_transactions).
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?
Provides explicit when-to-use scenarios with examples like 'What's my YTD return?' and 'Don't use when' cases, offering specific alternative tools (indexa_get_portfolio, indexa_get_transactions). This gives clear guidance for the AI agent to choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current portfolio of an Indexa account: total value, cash position, and the full list of instruments currently held (ISIN, name, asset class, market value, cost basis, unrealized P/L and return %).
API response shape: { "portfolio": { "total_amount", "cash_amount", "instruments_amount", "instruments_cost", "date" }, "cash_accounts": [{ "amount", "date" }], "instrument_accounts": [{ "positions": [{ "amount", "cost_amount", "price", "titles", "instrument": { "identifier"(ISIN), "name", "asset_class", "management_company_description" } }] }] }
The Markdown output includes: grand total, cost basis, total P/L and return %, breakdown by asset class with %, and per-position detail sorted by value.
Args:
account_number (string): Indexa account ID, from indexa_get_me
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Examples:
Use when: "What's my Indexa portfolio worth?"
Use when: "Show me what funds I'm holding"
Use when: "How much am I up/down on my Indexa account?"
Don't use for: historical returns → indexa_get_performance
Don't use for: transaction history → indexa_get_transactions
| Name | Required | Description | Default |
|---|---|---|---|
| account_number | Yes | Indexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'. | |
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context by detailing the API response shape and Markdown output, plus mentions dependency on account_number from indexa_get_me. No contradictions.
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 well-structured with clear sections: purpose, API shape, markdown output, args, examples. Every sentence contributes information without redundancy. Front-loaded with key purpose.
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?
Given no output schema, the description provides the full JSON response shape and details the Markdown summary format. It covers common use cases with examples. Comprehensive for a portfolio tool.
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 have detailed descriptions. The description adds extra value by providing an example account number and clarifying the difference between 'markdown' and 'json' output formats beyond the schema.
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 clearly states the tool retrieves the current portfolio composition, including total value, cash, and instrument details. It distinguishes from siblings like indexa_get_performance and indexa_get_transactions by explicitly listing what not to use it for.
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?
The description provides explicit when-to-use examples ('What's my Indexa portfolio worth?') and when-not-to-use examples with alternative tool names ('historical returns → indexa_get_performance'). This gives clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account_number | Yes | Indexa account number (account_number field from indexa_get_me). Example: 'NK1NUTP1'. | |
| date_from | No | Date in YYYY-MM-DD format. Example: '2024-01-15'. | |
| date_to | No | Date in YYYY-MM-DD format. Example: '2024-01-15'. | |
| limit | No | Maximum transactions to return after date filtering. | |
| offset | No | Number of transactions to skip after date filtering. | |
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
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.
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.
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.
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.
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.
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.
Convenience tool that returns a one-shot overview of ALL the user's Indexa Capital accounts: total wealth, per-account value, cash, unrealized P/L and cumulative return. Calls /users/me then /portfolio and /performance for each active account in parallel.
Use this as the FIRST tool for open-ended questions like "how are my Indexa investments doing?" or "give me an overview of my Indexa". Only use account-specific tools when the user specifies one account or aspect (composition, transactions, fees).
Args:
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns JSON: { "user": { email, name, surname }, "accounts": [{ account_number, type, status, total_value, cash, unrealized_pl, cumulative_return, plan_expected_return, error? }], "totals": { total_value, unrealized_pl, account_count } }
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable summary or 'json' for full structured data. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal calls to /users/me, /portfolio, and /performance in parallel. Describes return structure (user, accounts, totals). Adds value beyond annotations which already indicate read-only, idempotent, open-world.
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 concise paragraphs: first for purpose/usage, second for parameter/return. No wasted words.
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 no output schema, description provides full return structure in JSON format. Internal call details give sufficient behavioral context. Complete for an aggregator tool.
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?
Only one parameter (response_format) with 100% schema coverage. Description restates enum values and default but adds no new semantics beyond schema.
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?
Clearly states it returns a one-shot overview of ALL user's Indexa Capital accounts. Distinguishes from account-specific sibling tools by specifying scope and usage.
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?
Explicitly says to use as FIRST tool for open-ended questions and to use account-specific tools only when user specifies one account or aspect. Provides concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0indexa_get_accountindexa_get_feesindexa_get_meindexa_get_performanceindexa_get_portfolioindexa_get_transactionsindexa_portfolio_summaryScored across 7 tools
Each tool targets a distinct aspect of the Indexa Capital API: user profile, account info, portfolio, performance, transactions, fees, and an aggregated summary. Descriptions explicitly state what not to use each tool for, eliminating ambiguity.
All tools follow the 'indexa_get_<noun>' pattern except 'indexa_portfolio_summary', which uses 'summary' instead of 'get'. This is a minor deviation, but overall the naming is consistent and predictable.
With 7 tools covering user info, account details, portfolio, performance, transactions, fees, and an aggregated summary, the set is well-scoped for a read-only investment API. No tool feels superfluous or missing.
The tool set covers the core read-only operations for an investment account: user profile, account details, portfolio holdings, performance returns, transaction history, and fees. A summary tool aggregates key data. Minor gaps like tax documents or dividend details are acceptable for a read-only API.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP server for Muovi, Argentina's trust-first local services marketplace (6 tools).
