cvm-mcp
cvm-mcp
CVMの公開データポータルから直接財務データを取得・処理するMCPサーバーです。サードパーティに依存せず、公開企業が発表した財務諸表をLLMクライアント(Claude Desktop、Claude Codeなど)がツールを通じて照会できるようにします。
標準の表示は四半期ベースです。ツールは企業が最後に発表した四半期から始まり、過去12ヶ月分を四半期ごとに、CVMが公開する勘定科目そのまま(計算指標なし)で返します。
機能
ツール | 使用タイミング |
| 分析前に企業名/CNPJ/CVMコードを解決する場合 |
| 一般的な依頼(「企業Xを分析して」)— 過去4四半期のDRE |
| 別の財務諸表(貸借対照表、キャッシュフロー計算書)または4四半期超の場合 |
| ユーザーが明示的に年間決算(DFP)を要求した場合 |
すべての金額は**百万R$**に統一されています。下記の制限事項を参照してください。AIは派生データや取得できなかったデータについて常に警告を受け取ります。
Related MCP server: FinancialReports MCP Server
四半期の構成方法
CVMのITRは第1四半期、第2四半期、第3四半期のみを公開し、各四半期単独の数値に加えて年度累計も提供します。そのため、四半期を切り出すのは期間のフィルタリングであり、減算ではありません。
第4四半期はITRには存在しません。 これは 完全な会計年度(DFP)− 第3四半期までの累計(ITR) として、勘定コードごとに突き合わせて導出されます。このように導出された期間はすべて、応答に derivado: true のフラグと明示的な警告が付与されます。
理解しておくべき2つの結果:
在庫勘定は決して導出されません。 BPAおよびBPPは特定日付の残高であるため、会計年度末の値がそのまま第4四半期の値となります。流動勘定(DRE、DFC、DVA、DRA、DMPL)のみが減算の対象となります。
「最新の四半期」は企業ごとに異なります。 暦年以外の会計年度を採用する企業は、他の月に決算を迎えます。例えばCamil社は3–5月、6–8月、9–11月、12–2月を四半期としています。サーバーは各企業の日付に基づいてこれを解決し、ラベル(
2T26)には常にinicioとfimが付随します。
インストール
Python 3.10以上が必要です。Windows、macOS、Linuxで同じように動作します。
オプション1 — pipx(推奨、環境を分離)
pipx install .その後、任意のフォルダから cvm-mcp コマンドとして実行できます。
オプション2 — 仮想環境内のpip
python -m venv .venv
# Windows (PowerShell)
.venv\Scripts\Activate.ps1
# macOS / Linux
source .venv/bin/activate
pip install -e .オプション3 — ソースコードから直接、インストールせず
pip install -r requirements.txt # ou: pip install mcp[cli] httpx pandas platformdirs
python -m cvm_mcpClaude Desktopでの設定
claude_desktop_config.json を編集し(Windows: %APPDATA%\Claude\claude_desktop_config.json、macOS: ~/Library/Application Support/Claude/claude_desktop_config.json)、以下を追加します:
{
"mcpServers": {
"cvm": {
"command": "cvm-mcp"
}
}
}pipxでインストールしない場合(オプション3)は、以下を使用します:
{
"mcpServers": {
"cvm": {
"command": "python",
"args": ["-m", "cvm_mcp"]
}
}
}ローカルキャッシュ
CVMからダウンロードしたファイル(登録情報、ITRおよびDFPの年間ZIP)はローカルにキャッシュされ、問い合わせのたびに再ダウンロードしません。チェックはETag/Last-Modifiedを使用するため、CVMポータルの更新は自動的に検出されます。
サイズの目安:パッケージは圧縮状態(1年あたり約20~30MB)ですが、使用時に展開され、年・タイプごとに数百MBのディスク容量を消費します。四半期表示では通常、2年分のITRと1年分のDFPにアクセスします。
デフォルトの場所(platformdirs 使用、OSに依存しない):
Windows:
%LOCALAPPDATA%\cvm-mcpmacOS:
~/Library/Caches/cvm-mcpLinux:
~/.cache/cvm-mcp
別のディレクトリを使用する場合(例:制限された環境やCI)は、サーバー起動前に CVM_MCP_CACHE_DIR を設定してください。
重要な制限事項
第4四半期は導出値であり、公開されていません。 CVMは第4四半期単独の数値を開示しません。値は
通年 − 9ヶ月累計から導出されます。定義上、通年と一致しますが、企業が報告した数値ではありません。計算指標はありません。 本バージョンは公開された勘定科目を返すもので、マージン、ROE、EBITDAなどは含みません。指標のコードは引き続きリポジトリ内(
indicators.py、accounts.py)にありますが、どのツールにも接続されておらず、後日四半期ベースに再適合させるためのものです。市場データはありません。 CVMは株価、時価総額、倍率(P/E、EV/EBITDA)を公開していません。そのようなリクエストは本データソースの対象外です。
在庫勘定は合算しません。 BPAおよびBPPは残高です。4四半期の純資産を合計しても意味のある値は得られません。流動勘定のみが12ヶ月間の累計対象となります。
すべての企業が4四半期分を持っているわけではありません(最近のIPO、上場廃止、登録取消、ITRの提出遅延など)。存在する期間のみを返し、欠損をゼロで埋めることはしません。
金融セクターの企業はDREに異なる勘定科目体系を使用するため、勘定コードは非金融企業と各行で比較できません。
開発
python -m venv .venv
.venv\Scripts\Activate.ps1 # ou source .venv/bin/activate
pip install -e .
python -m cvm_mcp # roda o servidor via stdioプロジェクト構造:
src/cvm_mcp/
config.py # constantes e diretório de cache (cross-platform)
cache.py # download HTTP com cache condicional + extração de ZIP
parsers.py # leitura dos CSVs (encoding/separador da CVM)
cvm_client.py # busca de empresas e carregamento dos demonstrativos
quarters.py # montagem da janela trimestral e derivação do 4T
models.py # estruturas de dados (Company, Quarter)
server.py # servidor MCP (FastMCP) e definição das tools
accounts.py # (inativo) mapa do plano de contas -> itens financeiros
indicators.py # (inativo) cálculo de indicadores em base anualaccounts.py および indicators.py は、本バージョンではどのツールからもインポートされていません。四半期ベースで指標が再導入される際のベースとしてリポジトリに残されています。
Available Tools
4 toolsanalisar_empresaA
Análise financeira padrão dos últimos 5 anos de uma empresa.
Use quando o usuário pedir algo genérico como "analise a empresa X" sem especificar período ou indicadores. Retorna, em R$ milhões e por ano: Receita Líquida, EBIT, EBITDA estimado, Lucro Líquido, Margem Líquida, Margem EBITDA, ROE, Liquidez Corrente, Dívida Bruta, Caixa, Dívida Líquida e Dívida Líquida/EBITDA — sempre com avisos quando algum item não pôde ser calculado a partir dos demonstrativos públicos da CVM (ex: EBITDA é sempre uma estimativa, não o número "ajustado" da empresa; não há dado de cotação/valor de mercado nesta fonte). Para pedidos customizados (outro período, dado bruto, individual vs consolidado), use obter_indicadores ou obter_demonstrativo_bruto.
| Name | Required | Description | Default |
|---|---|---|---|
| nome_ou_cnpj | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses key behavioral traits: EBITDA is an estimate, data comes from CVM public filings, no market cap data, and warnings are issued when items cannot be calculated. This fully informs the agent about limitations.
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 and front-loaded: first sentence states purpose, second guides usage, third lists returns, fourth adds caveats. Every sentence adds value without redundancy.
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 tool's simplicity (single parameter, no output schema), the description is complete. It covers what is returned, constraints (5 years), limitations (EBITDA estimate, no market data), and provides usage guidance with alternatives.
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 0%, so the description should compensate. The parameter 'nome_ou_cnpj' is self-explanatory, but the description does not elaborate on format or provide examples. It gives context that it's a company identifier, which is adequate but not exceptional.
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 provides a standard financial analysis of the last 5 years of a company, with a specific list of metrics. It distinguishes from siblings by specifying it is for generic requests, while alternatives handle custom periods or raw data.
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 'use when user asks something generic like 'analyze company X' without specifying period or indicators.' It also tells when NOT to use (customized requests) and names alternative tools (obter_indicadores, obter_demonstrativo_bruto).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buscar_empresaA
Busca companhias abertas no cadastro da CVM por nome, CNPJ ou código CVM.
Use esta tool antes de qualquer outra para confirmar a empresa certa: existem nomes parecidos e empresas com registro cancelado/suspenso que podem não ter demonstrativos recentes.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| consulta | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches the CVM registry and that results may include companies with cancelled/suspended status, which is a useful behavioral trait. However, it does not mention any side effects, authentication needs, or return format.
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 sentences, front-loaded with the main action, and uses line breaks for readability. Every sentence adds value with no fluff.
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 search tool with 2 parameters and no output schema or annotations, the description covers purpose, usage guidance, and the main parameter. However, it omits explanation of the 'limite' parameter and return values, leaving minor gaps.
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 0%, so the description must compensate. It explains that 'consulta' can be a name, CNPJ, or CVM code, adding meaning. However, it fails to describe 'limite' (limit), which defaults to 10. Partial compensation leads to a score of 3.
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 verb (busca = searches), resource (companies in CVM registry), and search criteria (name, CNPJ, or CVM code). It distinguishes from sibling tools like analisar_empresa or obter_indicadores, which are for analysis and data retrieval, not searching.
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 this tool before any other to confirm the correct company, warning about similar names and cancelled/suspended registrations. This provides clear when-to-use and context-specific guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
obter_demonstrativo_brutoA
Devolve as contas contábeis brutas (código, descrição, valor em R$ milhões) de um demonstrativo publicado pela CVM, sem nenhum cálculo.
demonstrativo: um de BPA, BPP, DRE, DFC_MD, DFC_MI, DVA, DMPL, DRA. Use quando o usuário pedir algo que os indicadores prontos não cobrem, como uma conta contábil específica ou maior nível de detalhe.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | ||
| consolidado | No | ||
| nome_ou_cnpj | Yes | ||
| demonstrativo | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool returns raw data 'sem nenhum cálculo' (without any calculation), indicating it is a read-only operation. However, it does not mention potential side effects or response size considerations, but the core behavior is clear.
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 two sentences plus a list, front-loaded with the action ('Devolve as contas contábeis brutas...'). Every sentence adds value, and the structure is efficient.
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 tool has 4 parameters, no output schema, and 3 siblings, the description covers the core functionality, usage context, and return structure (code, description, value). It lacks details on error handling or missing data behavior, but overall it is sufficiently complete for its complexity.
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?
The input schema has 4 parameters with 0% description coverage. The description only adds meaning for the 'demonstrativo' parameter by listing valid values (BPA, BPP, DRE, etc.). Other parameters (nome_ou_cnpj, ano, consolidado) are not explained in the description, leaving their purpose inferred from context. This partially compensates for the schema gap but is insufficient for full clarity.
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 returns raw accounting accounts (code, description, value in BRL millions) from a CVM financial statement, without calculations. It lists specific statement types (BPA, BPP, DRE, etc.) and distinguishes itself from sibling 'obter_indicadores' by noting it provides raw detail when indicators are insufficient.
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 explicitly states when to use this tool: 'Use when the user asks for something that the ready indicators don't cover, like a specific accounting account or greater level of detail.' This provides clear guidance and implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
obter_indicadoresA
Indicadores financeiros calculados para um intervalo de anos escolhido pelo usuário (mesmos indicadores de analisar_empresa, mas com período e versão consolidado/individual livres). Use para pedidos customizados que fogem do padrão de 5 anos.
| Name | Required | Description | Default |
|---|---|---|---|
| ano_fim | Yes | ||
| ano_inicio | Yes | ||
| consolidado | No | ||
| nome_ou_cnpj | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns the same indicators as analisar_empresa but with free period and consolidation choice. However, it does not mention any behavioral traits like performance implications, data freshness, or error handling, which are important for a computation tool.
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 consists of two concise sentences that front-load the core purpose and usage context. No redundant or extra information is present; every word contributes meaning.
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 tool has 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the returned indicators, parameter details (especially nome_ou_cnpj and consolidado), or error conditions. A user would need additional context 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?
The input schema has zero parameter descriptions (0% coverage). The description only partially explains ano_inicio, ano_fim, and consolidado via the phrase 'intervalo de anos' and 'versão consolidado/individual'. It does not clarify consolidado's meaning or the nome_ou_cnpj parameter at all. This is insufficient compensation for the missing schema descriptions.
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 that the tool computes financial indicators for a user-chosen year range, and distinguishes it from sibling analisar_empresa by emphasizing flexibility in period and consolidation version. It uses a specific verb ('calculados') and resource ('indicadores financeiros'), making the purpose unambiguous.
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 explicitly advises to use this tool for custom requests that deviate from the standard 5-year period, implying that analisar_empresa should be used otherwise. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
analisar_empresa - First observed
buscar_empresa - First observed
obter_demonstrativo_bruto - First observed
obter_indicadores
TDQS
Scored across 4 tools
Each tool serves a distinct purpose: buscar_empresa for company lookup, analisar_empresa for standard 5-year analysis, obter_indicadores for custom analysis, and obter_demonstrativo_bruto for raw accounting data. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in Portuguese (e.g., analisar_empresa, buscar_empresa). The naming is predictable and clear.
With 4 tools, the server is well-scoped for its domain. It covers company search, standard analysis, custom analysis, and raw data retrieval without unnecessary bloat.
The tool set covers core workflows: identification, standard analysis, custom analysis, and raw data. A minor gap is the absence of a tool for comparing multiple companies or exporting data, but the essential functionality is present.
Maintenance
Related MCP Connectors
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Your agent needs company financials it can compute on — statements, ratios, earnings, estimates, filings and insider activity as structured data, not a PDF. **What you can ask for** • "Give me 8 quarters of income statement, balance sheet and cash flow for this ticker." • "What do analysts estimate for next quarter, and how did the last four surprise?" • "Find this exact line item across every filing." • "Who bought or sold as an insider in the last 90 days?" • "Screen for profitable companies under this valuation with growing revenue." **How to use it** Point any MCP client at https://mcp.aisa.one/marketpulse/mcp and sign in with OAuth — there is no key to create or paste. 21 tools: prices and snapshots, income statements, balance sheets, cash-flow statements, financial metrics and snapshots, earnings, analyst estimates, company facts, filings and filing items, line-item search, a screener, insider trades, macro interest rates, news, plus EDINET documents and filing digests for Japanese issuers. **Why this rather than the source** Statements as fields you can compute on, and a screener in the same place. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the fundamentals here, then ask the same agent what social is saying about the ticker — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Your agent needs markets — prices and fundamentals for listed companies, the filings behind them, crypto, and what the prediction markets put the odds at. **What you can ask for** • "Pull this company's income statement, cash flow and balance sheet for the last 8 quarters." • "What did insiders buy or sell, and when?" • "Snapshot prices for these 50 tickers, then the OHLC history for the three that moved." • "What are the current odds on this event across Kalshi and Polymarket?" • "Screen for companies matching these financial criteria." **How to use it** Point any MCP client at https://mcp.aisa.one/finance/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: prices and snapshots, income statements, balance sheets and cash flows, metrics and ratios, earnings and analyst estimates, filings and line-item search, insider trades, macro interest rates, news, a screener; CoinGecko spot prices, market tables, OHLC, per-venue tickers and trending; Kalshi and Polymarket markets and trades; plus EDINET filings for Japan. **Why this rather than the source** Equities, crypto and event markets behind one account, so a cross-asset question is one conversation. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the number here, then ask the same agent what X is saying about the ticker today — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/marketpulse/mcp · /crypto-market-data/mcp · /prediction-market-data/mcp · /stock-pulse/mcp for one slice each.
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP Server for accessing 36 Brazilian public data sources and 1 agent, enabling AI agents to query government data on economy, legislation, transparency, judiciary, elections, environment, health, and more.6MIT
- AlicenseNot gradedqualityBmaintenanceOfficial MCP server for the FinancialReports API. Provides direct access to regulatory filings, financial data, and corporate information from listed companies worldwide via 15 curated tools.2MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that exposes real-time financial data tools for stock search, company info, historical prices, and financial metrics from Yahoo Finance, enabling AI agents to answer natural-language questions about stocks and financial markets.MIT
- AlicenseAqualityBmaintenanceMCP server that lets an LLM read official SEC financial data, tracing every number back to a specific SEC filing, US-GAAP tag, and filing date.4MIT