Skip to main content
Glama
Sign In

Dados B3

by io.github.Val7h
OverviewDiscussionsAdmin

Companhias que saíram da bolsa, por ano (B3 e CVM)

saiu_da_bolsa
Read-onlyIdempotent

Quais empresas saíram da bolsa (deixaram de negociar na B3) em cada ano, com data e motivo. Use quando: "quais empresas saíram da bolsa em 2026?"; "a Petz saiu da B3? quando foi o último pregão?"; "quantas companhias fecharam o capital em 2025?". NÃO use para: dividendos que uma delistada pagou → dividendos; desdobramentos e cisões → eventos; fato relevante da saída → fatos_relevantes. Fonte e fórmula: COTAHIST da B3 (último pregão) e cadastro de companhias abertas da CVM (cancelamento, data e motivo); entram também as que pararam de negociar com registro ativo (fusão, OPA, mudança para fora); sem BDRs. Retorna: por_ano {ano: [companhias com código, nome, último pregão e, se cancelada, data e motivo]}, contagem, criterio, fonte, pagina, citacao. Vazio ou erro: só os 3 anos mais recentes; ano fora deles devolve erro com os anos disponíveis. Ano sem saída = lista vazia. Acesso: Gratuita, sem chave.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "saiu_da_bolsa"
  }
}

Input Schema

NameRequiredDescriptionDefault
anoNoAno do último pregão, dentro dos 3 mais recentes (ex.: 2025). 0 = os 3 anos mais recentes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ano / description
      Added value: +"Ano do último pregão, dentro dos 3 mais recentes (ex.: 2025). 0 = os 3 anos mais recentes."
  2. Added

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real context beyond that: the data sources (COTAHIST last trading session plus CVM open-company registry), what counts as a delisting (including mergers, tender offers, moves abroad), the exclusion of BDRs, and the free/no-key access model. It does not mention rate limits or latency, so a 3 rather than a 5 with annotations already carrying the safety profile.

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?

Labeled sections (use when, do not use, source/formula, returns, empty/error, access) make it scannable and front-loaded. Slightly verbose, with the return-field enumeration partially duplicating what the source section implies, but no sentence is wasted.

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?

With no output schema, the description compensates by enumerating the return payload (`por_ano`, `contagem`, `criterio`, `fonte`, `pagina`, `citacao`) and by spelling out edge-case behavior for empty results and out-of-range years. For a single-optional-parameter read tool this leaves nothing an agent needs unresolved.

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

Parameters3/5

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

Schema coverage is 100% and the single `ano` parameter already documents 'within the 3 most recent years' and '0 = os 3 anos mais recentes'. The description does add error semantics — a year outside the window returns an error listing available years, and a year with no delistings returns an empty list — but that is marginal on top of a fully documented schema, so the baseline 3 holds.

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?

States a specific verb and resource: which companies stopped trading on B3, broken down by year, with date and reason. The scope is narrowed precisely (B3 + CVM registry, no BDRs), which lets an agent separate it from `eventos`, `dividendos`, or `listar_empresas` without opening the 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 three realistic user phrasings and an explicit 'NÃO use para' block that routes each adjacent need to a named sibling (`dividendos`, `eventos`, `fatos_relevantes`). This is exactly the when/when-not/alternatives triad.

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

All Dados B3 toolsInspect
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.

Resources