Skip to main content
Glama

Mercado Pago MCP

by io.github.mcp-dir

openfinance_list_investments

Read-onlyIdempotent

Returns the investment portfolio for a connection (broker or bank with INVESTMENTS product enabled): FIIs, stocks, ETFs, fixed income (CDB/LCI/LCA/Tesouro), mutual funds, retirement (previdência) and COE. Each row carries balance, amount, amountOriginal, amountProfit, lastMonthRate / annualRate / lastTwelveMonthsRate (when available), dueDate, issuer, ISIN, etc. Returns { total:0, results:[], warning } instead of throwing when INVESTMENTS isn't enabled (403) or other upstream errors. DATA INTEGRITY: when MULTIPLE positions come back as TOTAL_WITHDRAWAL with balance/quantity 0 at once (mass zeroing), the tool cross-checks each position's own transaction history upstream; if the zeroing is contradicted (BUY with no sale/redemption/transfer) the response carries data_integrity_warning and the affected rows are flagged integrity:'suspect_zeroed' — treat those balances as UNAVAILABLE (likely a temporary connector failure publishing zeros), never as real R$0, and do NOT sum them into the portfolio.

Bulk support: accepts item_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNo
pageNo
typeNo
item_idNo
item_idsNo
page_sizeNo

TDQS

A4.1/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral details: error handling (returns a warning object instead of throwing 403), and a detailed data integrity mechanism with flags like 'suspect_zeroed'. This transparency helps agents handle edge cases correctly.

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 a clear front-loaded purpose, followed by field details, error handling, and a data integrity section. While slightly verbose, each sentence adds value and the bulk support note is useful. It is efficient for the complexity involved.

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

Completeness4/5

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

Given the lack of output schema and schema descriptions, the description provides a solid overview of return structure (total, results, warning), error handling, and data integrity warnings. It misses explicit explanations for parameters like page and page_size, but overall it sufficiently equips an agent to use the tool.

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?

With 0% schema coverage, the description adds minimal parameter guidance. It mentions bulk support for item_ids and implies item is a connection ID, but does not explain page, page_size, or type filtering. The enum for type is listed but not linked to the parameter, leaving agents to infer functionality.

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 that the tool returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and fields (balance, amount, rates). It distinguishes from siblings like 'openfinance_list_investment_transactions' by focusing on holdings/positions rather than transactions.

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 implies usage for retrieving investment portfolio data and mentions bulk support via item_ids, but does not explicitly contrast with alternative tools like list_investment_transactions. The context is clear enough for an agent to infer when to use this tool.

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

All Mercado Pago 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.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose. Even overlapping-looking tools like list_transactions vs list_transactions_by_item are clearly differentiated (per-account vs consolidated per-connection), and get vs list variants follow standard conventions. The marketplace tool bundles multiple actions but is its own meta-tool. No two tools appear to do the same thing.

Naming Consistency4/5

The openfinance_ prefix provides a consistent pattern for banking operations, with clear get/list/update/force_sync verbs. A few non-prefixed meta tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) break the pattern, but they represent different functional domains and are still readable. Overall the convention is predictable.

Tool Count3/5

At 25 tools, this is on the heavy side per the calibration guidelines (16-25 feels heavy). However, the breadth of Open Finance resources (accounts, transactions, investments, loans, credit cards, connections, plus meta operations) largely justifies the count. It's borderline and could benefit from consolidation, but it's not excessive.

Completeness4/5

The tool surface covers the domain comprehensively: listing and getting accounts, transactions, investments, loans, credit card bills, connections, status, sync, category management, and provider health. Missing operations are minor (e.g., no explicit 'get single transaction' but list covers it; no create/update on banking data besides category and disconnect). Core workflows are fully supported.

Resources