Dados B3

Fundos que têm uma ação na carteira (CDA da CVM)

fundos_da_acao

Read-onlyIdempotent

Quais fundos de investimento têm uma AÇÃO na carteira, quanto têm e quem aumentou ou reduziu no mês. Use quando: "quais fundos têm PETR4?"; "os fundos venderam WEGE3 no último mês?". NÃO use para: dados de um fundo pelo CNPJ → fundos_investimento; carteira de um ETF → etf. Fonte e fórmula: CDA (Composição e Diversificação das Aplicações) entregue à CVM, bloco de ações, 13 meses (ODbL); a carteira sai depois do fim do mês. Retorna: maiores fundos por valor {fundo, valor, quantidade}, contadores e maiores movimentos de todos os fundos, e a data de referência. Vazio ou erro: lista vazia = nenhum fundo declarou a ação no mês de referência. limite vai de 1 a 500. Acesso: WEGE3 sem chave; demais ações exigem chave_api (grátis).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "fundos_da_acao"
  }
}

Input Schema

Name	Required	Description
`limite`	No	Quantidade de fundos listados, inteiro de 1 a 500 (padrão 20), os maiores por valor.
`ticker`	Yes	Código de AÇÃO na B3, ex.: PETR4, VALE3, ITUB4. Aceita petr4, PETR4.SA, BVMF:PETR4, PETR4F (fracionário) e código antigo (vira o atual). Código de FII, ETF ou BDR devolve erro com `tente_assim`.
`chave_api`	No	Chave de API opcional. Vazia = acesso aberto: a descrição da ferramenta diz se devolve amostra ou exige chave (chave grátis, sem cartão).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

changedInput schema / properties / ticker / description

Previous value: -"Ticker da B3, como PETR4, VALE3 ou WEGE3 (sem distinção de caixa; aceita o sufixo .SA)."New value: +"Código de AÇÃO na B3, ex.: PETR4, VALE3, ITUB4. Aceita petr4, PETR4.SA, BVMF:PETR4, PETR4F (fracionário) e código antigo (vira o atual). Código de FII, ETF ou BDR devolve erro com `tente_assim`."

addedInput schema / properties / ticker / examples

Added value: +[
+  "PETR4",
+  "VALE3",
+  "ITUB4"
+]

Changed3 schema fields changedNov 5, 2026

addedInput schema / properties / chave_api / description

Added value: +"Chave de API opcional. Vazia = acesso aberto: a descrição da ferramenta diz se devolve amostra ou exige chave (chave grátis, sem cartão)."

addedInput schema / properties / limite / description

Added value: +"Quantidade de fundos listados, inteiro de 1 a 500 (padrão 20), os maiores por valor."

addedInput schema / properties / ticker / description

Added value: +"Ticker da B3, como PETR4, VALE3 ou WEGE3 (sem distinção de caixa; aceita o sufixo .SA)."

AddedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safe-read profile (readOnly, idempotent, non-destructive); the description adds substantive behavior beyond that: data origin (CDA filings to CVM, stock block, 13 months, ODbL), the publication lag ('a carteira sai depois do fim do mês'), what an empty list means, and the access rule (WEGE3 without a key, other tickers require a free API key). It also states the shape of the return, which matters since there is no output schema.

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?

Front-loaded one-sentence summary followed by clearly labeled blocks (Use quando / NÃO use / Fonte / Retorna / Vazio ou erro / Acesso), which scans well. A few lines are marginally redundant with the schema (the `limite` range) and with each other, but there is no filler.

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?

For a read-only, single-ticker tool with no output schema, the description covers everything an agent needs: what comes back, the reference date, the lag before data appears, the meaning of an empty result, and the authentication requirement per ticker. No return-value explanation is missing.

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%, so the baseline is 3, but the description adds real meaning beyond the schema: it resolves the `chave_api` placeholder text by telling the agent that only WEGE3 is open-access and other tickers need a key, and it frames `limite` as covering the largest funds by value. The 1–500 range restates the schema, which is why this is not a 5.

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 opening line states a specific verb and resource: which investment funds hold a given stock, how much they hold, and who increased or reduced in the month. It explicitly names the sibling tools it is not (`fundos_investimento` for a fund by CNPJ, `etf` for an ETF portfolio), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Provides an explicit 'Use quando' block with two concrete example queries ("quais fundos têm PETR4?", "os fundos venderam WEGE3 no último mês?") and a 'NÃO use para' block that names both alternatives and the condition that selects them. Nothing about tool selection is left to inference.

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

All Dados B3 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.