Skip to main content
Glama
Sign In

Dados B3

by io.github.Val7h
OverviewDiscussionsAdmin

Screener de ações

screener
Read-onlyIdempotent

Filtra as AÇÕES do universo por faixas de indicadores (só ações — para fundo imobiliário use screener_fiis, cujos filtros são outros: P/VP, DY, segmento, cotistas). filtros é um dict tipo {"roic_min": 0.15, "dl_ebitda_max": 2}. Indicadores: roic, roe, margem_bruta, margem_ebit, margem_liquida, dl_ebitda, cresc_receita_1a, cresc_receita_5a_cagr (sufixos _min/_max) e os múltiplos pl (P/L anual, da DFP) e pl_ttm (P/L de 12 meses, do ITR ou DFP mais recente), ex. {"pl_max": 10}; P/L negativo, acima de 200 ou ausente nunca passa e a linha traz multiplos com dt_receb, data_preco e ressalvas do valor (rigor="estrito" só aceita P/L sem nenhuma ressalva; fora_do_filtro explica quem ficou de fora). Sem ano usa o último de cada empresa. as_of ("AAAA-MM-DD") responde outra pergunta: o que estava PÚBLICO naquela data (balanço já recebido pela CVM, ~100 dias depois do exercício) — use para pesquisa sem olhar o futuro; cada linha traz disponivel_em. ano e as_of não se combinam. O universo continua o das companhias ativas hoje (viés de sobrevivência, declarado na resposta). recibo=True congela a resposta num endereço permanente com o sha256 do resultado — use quando for CITAR a lista, porque ela muda quando a base for atualizada e o recibo não. Só valores SEM flag entram. Requer chave_api (grátis ou Pro).

Input Schema

NameRequiredDescriptionDefault
anoNo
as_ofNo
rigorNopadrao
reciboNo
filtrosYes
chave_apiNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / rigor
      Added value: +{
+  "default": "padrao",
+  "title": "Rigor",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / recibo
      Added value: +{
+  "default": false,
+  "title": "Recibo",
+  "type": "boolean"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / as_of
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "As Of"
+}
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare the read-only/idempotent/non-destructive profile, yet the description adds substantial behavior: only unflagged values pass, P/L negative/above 200/absent is always rejected, `rigor="estrito"` rejects any P/L with a caveat, `fora_do_filtro` reports exclusions, `multiplos` exposes `dt_receb`/`data_preco`/`ressalvas`, the result carries a declared survivorship bias, and `recibo=True` freezes the answer with a sha256. It also flags the `chave_api` requirement.

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?

Purpose and sibling routing are front-loaded and no sentence is filler, but the paragraph is long and run-on, with parameter, temporal, and receipt semantics interleaved rather than grouped. Dense and effective, yet a reader must work through it linearly.

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 6-parameter tool with a free-form nested dict, no schema descriptions, and no output schema, the description covers filtering syntax, temporal semantics, caveat handling, response fields, and citation mode. Nothing needed to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry full burden—and it does. It documents the nested `filtros` dict shape with concrete examples, lists the valid indicators and the `_min`/`_max` suffix convention, explains `pl` (annual P/L from DFP) vs `pl_ttm` (trailing 12m), and defines `ano`, `as_of`, `rigor`, `recibo`, and `chave_api` semantics.

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 precise verb+resource ('Filtra as AÇÕES do universo por faixas de indicadores') and immediately demarcates scope against the sibling 'screener_fiis', noting that fund filters differ (P/VP, DY, segmento, cotistas). An agent can distinguish the two tools without opening either 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?

Explicitly routes: use this for stocks, use `screener_fiis` for real estate funds. It also disambiguates the two temporal parameters (`ano` = latest per company vs `as_of` = what was public on a date, and that they cannot be combined) and states when to set `recibo=True` (when citing the list, because it otherwise changes). Conditions for selection are given, not inferred.

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