mcp-brasil レビュー: ブラジル公共データ70ソースを MCP 経由で LLM に渡す

70 の公共データソースを 1 つの MCP サーバーに束ねるという発想

ブラジルの公共データは、連邦政府の Portal da Transparência、議会の Câmara と Senado、中央銀行の SGS、各州の会計検査院 (TCE) など、組織ごとに別々の API として存在する。エンドポイントの形式も認証方式もページネーションの作法も揃っていない。LLM に「2024 年の連邦契約の上位 10 件とその供給元を調べろ」と頼むには、その前に誰かが 10 種類の API クライアントを書いてツールとして公開しなければならない。mcp-brasil はその前段を引き受けるサーバーで、README によれば 70 features にまたがる 533 tools と 131 resources、102 prompts を 1 つの MCP エンドポイントから見せる。対象読者は、Claude や GPT などのエージェントにブラジルの公的データを調べさせたいが、API ごとの差分を自分で吸収したくない開発者やデータジャーナリストだ。README は「Projeto independente」と明記し、ブラジル政府の公式サービスではないと断っている。

533 tools をどう絞り込むか: BM25 search transform と自動レジストリ

ツールが 533 個あると、モデルのコンテキストに全部のスキーマを載せるのは非現実的だ。README はこの問題に対して BM25 search transform を使い、その時点の文脈に関連するツールだけをモデルに見せると説明している。つまり全ツール定義を常時注入するのではなく、検索で候補を絞る層が挟まっている。もう 1 つの設計上の特徴が auto-registry で、README の表現では「機能を追加するとはフォルダを作ること」にあたり、手動の登録作業が不要だとされている。70 ソースという規模を維持するには、この追加コストの低さが効いてくる。ただし discovery が効くのはツール選択の段階であって、選ばれたツールが返すデータの正しさを保証するものではない。検索クエリの書き方次第で必要なツールが候補から落ちる可能性は残る。

大規模データセットは DuckDB にローカルキャッシュする

70 のソースのうち一部は API ではなく、まとまったデータセットとして配布されている。README が挙げているのは SIAPA の約 81.3 万件の不動産、TSE の 2014 年から 2024 年までの候補者・資産・投票・ソーシャルメディア・FEFC、ANP の燃料価格、INEP の学校センサスと ENEM、ISP-RJ の治安統計、ANAC の航空機と定期便だ。これらは embedded の DuckDB に対して SQL で問い合わせる形になり、README によれば環境変数による opt-in で有効化する。API を都度叩くのではなくローカルに持つ判断は、更新頻度の低い政府統計に対しては妥当だ。代わりに、初回のデータ取得とディスク容量、そしてキャッシュが古びたときに誰が更新するのかという運用責任が利用者側に移る。README からはキャッシュの自動更新間隔を読み取れないので、そこは導入前に確認したい。

複数 API をまたぐ planejar_consulta と executar_lote

README の例で最も実務に効くのは cross-reference だ。「Compare os gastos per capita com saúde em São Paulo e Minas Gerais cruzando dados do TCE-SP e IBGE」という問いは、単一 API では答えられない。mcp-brasil は planejar_consulta で複数 API を組み合わせた実行計画を生成し、executar_lote で複数のクエリを 1 回の呼び出しで並列に投げると説明している。たとえば「ある議員の支出 + 投票行動 + 提出法案」を 1 つのプロンプトから引く流れが README に示されている。ここで注意したいのは、計画の生成がモデル側の推論に依存する点だ。どのツールをどの順で呼ぶかが毎回変わりうるので、同じ質問でも結果の網羅性が一定しない。再現性が要求される調査では、生成された計画を保存して再利用する運用が要る。

インストールとクライアント設定: uvx 経由で 4 行の JSON

導入は pip install mcp-brasil か uv add mcp-brasil で入れる。クライアント側の設定はどのツールでもほぼ同じ形で、Claude Desktop なら claude_desktop_config.json、Google Antigravity なら ~/.gemini/config/mcp_config.json またはワークスペースの .agents/mcp_config.json、VS Code と Cursor ならプロジェクト直下の .vscode/mcp.json に次のブロックを足す。command は uvx、args は ["--from", "mcp-brasil", "python", "-m", "mcp_brasil.server"]、env に TRANSPARENCIA_API_KEY、DATAJUD_API_KEY、META_ACCESS_TOKEN を並べる。Claude Code なら claude mcp add mcp-brasil -- uvx --from mcp-brasil python -m mcp_brasil.server の 1 行で済む。HTTP で使いたい場合は fastmcp run mcp_brasil.server:mcp --transport http --port 8000 を実行し、http://localhost:8000/mcp に接続する。README はキーを省略しても残りの API が動くと書いているが、冒頭の記述ではキー不要が 66、無料キーが必要なものが 4 とされており、キー省略時に動く本数として本文中に「36」という数字も出てくる。この 2 つの数字は一致していないので、どの機能がキーなしで実際に応答するかは自分で確かめる必要がある。

MIT が覆うのはコードだけ: SOURCES.md と ACCEPTABLE_USE.md の分離

このプロジェクトのライセンス構成は素直ではない。リポジトリのライセンスは MIT だが、README は MIT が対象とするのはコードのみで、各データソースにはそれぞれ固有のライセンスがあり SOURCES.md に記載されていると明示している。加えてサーバーの利用自体が ACCEPTABLE_USE.md の許容利用ポリシーに服するとされ、商用・報道・意思決定目的で使う前には両方を読むよう求めている。つまり pip install して動かせたとしても、その先で得たデータをどう使えるかは別問題だ。政府 API の多くはレート制限や再配布条件を持つため、この分離は誠実な設計だと言えるが、利用者にとっては確認作業が 1 つ増えることを意味する。ライセンス解釈の判断はここでは扱わない。

向かないケース: 単一 API で足りるとき、出典を厳密に追うとき

70 ソースを束ねる利点は、複数の組織をまたぐ問いでこそ出る。逆に、中央銀行の Selic 系列だけが欲しい、Câmara の API を 1 つ叩きたいという用途では、mcp-brasil を挟む分だけ構成要素が増える。README が挙げる 70 features のうち、transparencia が 54 tools、senado が 26 tools と突出している一方、tce_sc は 2 tools、tce_sp は 3 tools しかない。特定の州の検査院データを深く掘る目的では、その州の API を直接叩いたほうが得られる項目は多い可能性がある。もう 1 つの限界は抽象化の代償だ。ツールが返すのは API レスポンスを整形した結果であり、生の JSON そのものではない。一次ソースのフィールドを逐一確認しながら記事や報告書を組み立てる調査では、整形の過程で何が落ちたかを追えない。この用途では API を直接呼ぶほうが安全だ。

代替手段との違い: 自前ラッパーか、汎用 HTTP ツールか

現実的な代替は 2 つある。1 つは各 API のクライアントを自分で書き、必要なツールだけを MCP として公開する方法。差分は制御範囲にある。自前なら返すフィールドもエラー時の挙動も完全に決められるが、70 ソース分の保守を引き受けることになる。mcp-brasil はその保守を上流に委ねる代わりに、出力形式とレート制限の扱いをプロジェクトの判断に任せる。もう 1 つは、汎用の HTTP リクエストツールを 1 つだけエージェントに渡し、モデルに URL を組み立てさせる方法。こちらは追加の依存が不要な反面、エンドポイントの仕様や認証、ページネーションを毎回モデルが正しく扱えるかに依存する。533 tools という規模は、この 2 番目のアプローチが実務で破綻しやすいことの裏返しでもある。mcp-brasil はスキーマを事前に定義してモデルの推測を減らす方向に振っている。

更新頻度と保守コストをどう見るか

リポジトリの最終 push は 2026-08-19、直近のリリースは v0.14.0 (2026-04-24)、その前に v0.13.0 が同日、v0.12.1 が 2026-04-14 と続く。4 月に短期間で 3 版が出たあと、8 月まで push が続いているという並びで、活発に手が入っている時期と落ち着いている時期の差は読み取れるが、今後のリリース間隔をここから予測はできない。保守コストとして利用者に残るのは、依存する上流 API の仕様変更に追随するかどうかの判断だ。ブラジル政府の API は予告なくフィールドが変わる例があり、そのたびに mcp-brasil 側の更新を待つか、自分でパッチを当てるかを選ぶことになる。auto-registry の設計は、そうした修正をフォルダ単位で足せるようにしている点で保守側に有利だが、利用者側の追従コストがゼロになるわけではない。

編集部の結論

ブラジルの立法、財政、選挙、司法データを LLM から横断的に引きたい分析者にとって、mcp-brasil は個別 API を自分でラップする作業を置き換える現実的な選択肢になる。逆に、単一の API だけを使う場合や、回答の根拠を一次ソースの生レスポンスまで厳密に追跡する必要がある調査には向かない。導入前に確認すべきは 3 点で、ACCEPTABLE_USE.md と SOURCES.md を読んで自分の用途が許容範囲か判断すること、TRANSPARENCIA_API_KEY と DATAJUD_API_KEY を取得してキー必須の 4 API を有効化すること、そして planejar_consulta が返す実行計画を一度手で読んで、どのツールがどの API を叩くのか把握しておくことだ。

公式情報源

1. Issues
2. License: MIT
3. Mcp-Brasil/mcp-brasil on GitHub
4. README
5. Releases