MCP-Server für brasilianische Außenhandelsdaten — mit den in der Antwort korrigierten Fallstricken des Datensatzes.
Vier Tools, die nicht lügen, statt vierzig, die nichts wissen.
Ein MCP-Server, der einen Datensatz nur exponiert, übergibt dem Agenten eine saubere API für eine falsche Zahl. Die Infrastruktur weiß nicht, dass das Feld lügt.
Comex Stat — die offizielle Außenhandelsdatenbank Brasiliens, veröffentlicht von der Secretaria de Comércio Exterior / Receita Federal — hat einen Defekt, vor dem keine Dokumentation warnt:
Filtert man das Transportmodus-Feld nach
AÉREA, erhält man 139,6 Mio. kg Importe aus China im Jahr 2026 (Jan–Jul). Kreuzt man dieselben Datensätze mit dem Verzollungspunkt, haben nur 34,0 Mio. (24 %) einen Flughafen passiert. Die übrigen 89,7 Mio. wurden in Seehäfen verzollt und bestehen aus Ammoniumsulfat und Phosphatdünger — Fracht, die nicht fliegt, zu 0,29 US$/kg Fracht.Ohne Korrektur: Luftgewicht 4,1× aufgebläht und Fracht pro Kilo um 70 % unterbewertet. Der Fehler ist still: Nichts in der Abfrage weist darauf hin.
Dieser Server wendet die Korrektur an und liefert zugleich die Belege dafür, warum sie nötig ist.
Related MCP server: Receita Federal: Radar (Habilitação Comércio Exterior)
Jede Antwort enthält die bekannten Fehler, die für diese Abfrage gelten, mit gemessenen Belegen und Herkunft der Überprüfung.
Die kritische Korrektur ist im Ergebnis angewendet, nicht nur angekündigt. Der Kanal air bedeutet bereits „auf dem Flughafen abgefertigte Luftfracht“. Der kontaminierte Block bleibt absichtlich als air_declared_at_port abfragbar — für alle, die ihn prüfen möchten.
Die Importdateien enthalten VL_FRETE und VL_SEGURO — Fracht und Versicherung, wie beim Zoll angegeben. Es ist das beste öffentlich verfügbare systematische Maß für realisierte Kosten, und praktisch niemand nutzt es.
China → Brasilien, Jan–Jul 2026, bereits korrigiert:
Kanal | Gewicht (kg) | Fracht US$/kg | Fracht % vom FOB | Wertdichte |
Luft (Flughafen) | 33.993.130 | 10,81 | 9,37 % | US$ 115,36/kg |
See | 16.074.641.185 | 0,142 | 5,68 % | US$ 2,51/kg |
Luftfracht kostet 76× mehr pro Kilo und nur 1,65× mehr pro Dollar Warenwert. Die Verkehrsträgeraufteilung dieses Korridors ist keine Frachtentscheidung — sondern eine Entscheidung über die Wertdichte.
Erfordert Node ≥ 22.5 (nutzt das eingebaute SQLite — null native Abhängigkeiten, kein node-gyp).
git clone <repo> && cd mcp-comex-brasil
npm install && npm run build
npm run db:build -- --years 2025,2026 # baixa da fonte oficial e monta o SQLitedb:build lädt die Dateien direkt von balanca.economia.gov.br. Dieses Paket verteilt keine Daten weiter — die Datenbank wird auf Ihrer Maschine gebaut, immer frisch von der Quelle.
Nützliche Optionen:
npm run db:build -- --years 2026 --countries 160 # só China, base pequena e rápida
npm run db:build -- --years 2024,2025,2026 --flows import,export{
"mcpServers": {
"comex": {
"command": "node",
"args": ["--experimental-sqlite", "/caminho/para/mcp-comex-brasil/dist/index.js"],
"env": { "COMEX_LANG": "pt" }
}
}
}COMEX_LANG akzeptiert pt (Standard) oder en. COMEX_DB überschreibt den Pfad zur Datenbank.
Tool | Funktion |
| Wert, Gewicht und Wertdichte nach Jahr, Monat, Land, NCM und Kanal. Der Kanal |
| Erklärte Fracht und Versicherung pro Kanal: US$/kg und % vom FOB. Nur Importe. |
| Die bekannten Fehler des Datensatzes, mit Belegen, Korrekturregel und Prüfliste. |
| Löst Land, NCM, Verkehrsträger und Zollstelle auf (mit Klassifizierung Flughafen/Hafen/Sonstiges). |
id | Schweregrad | Korrigiert? |
| kritisch | ✅ automatisch (Abgleich mit dem Verzollungspunkt) |
| kritisch | ❌ unmöglich — der Wert existiert nicht in der Quelle |
| info | — |
| Warnung | ❌ erfordert Jahresvergleich |
Zu simplified_regime_absent: Es gibt Verkehrsträger-Codes für POSTAL und COURIER, aber sie sind leer (13 Datensätze und 72 kg für China im gesamten Jahr 2026, gegenüber ~180 Millionen gemeldeter internationaler Sendungen). Sendungen mit geringem Wert laufen über das vereinfachte Verfahren und fließen nicht in die Handelsstatistik ein. Formale Statistik und Sendungsvolumen sind getrennte Welten — nicht addieren, nicht arithmetisch vergleichen.
Die Aggregate wurden per Kreuzimplementierung validiert: Derselbe Ausschnitt, verarbeitet durch einen awk-Durchlauf über die rohe CSV und durch die SQL-View dieses Servers, ergibt bis zur letzten Ziffer identische Zahlen (349.250 Datensätze, 7 Kanäle, Fracht- und Gewichtswerte).
npm test # 12 testes da lógica de classificação e do registro de caveatsMIT. Daten: Comex Stat, Secretaria de Comércio Exterior / Receita Federal do Brasil (balanca.economia.gov.br) — öffentliche Quelle, beim Aufbau der Datenbank abgerufen.
Autor: Luis Delfin
MCP-Server für brasilianische Außenhandelsdaten — mit den in der Antwort korrigierten Fallstricken des Datensatzes.
Vier Tools, die nicht lügen, statt vierzig, die nichts wissen.
Ein MCP-Server, der einen Datensatz nur exponiert, übergibt dem Agenten eine saubere API für eine falsche Zahl. Die Infrastruktur weiß nicht, dass das Feld lügt.
Brasiliens offizieller Handelsdatensatz (Comex Stat, veröffentlicht vom Foreign Trade Secretariat / Federal Revenue Service) hat einen Defekt, vor dem keine Dokumentation warnt:
Filtert man das Transportmodus-Feld nach
AIR, erhält man 139,6 Mio. kg Importe aus China für Jan–Jul 2026. Kreuzt man dieselben Datensätze mit ihrem Verzollungspunkt, sind nur 34,0 Mio. (24 %) durch einen Flughafen gegangen. Die übrigen 89,7 Mio. wurden in Seehäfen verzollt und bestehen aus Ammoniumsulfat und Phosphatdünger — Fracht, die nicht fliegt, zu 0,29 US$/kg Fracht.Unkorrigiert: Luftgewicht um 4,1× überhöht und Fracht pro kg um 70 % unterbewertet. Der Fehler ist still — nichts in der Abfrage weist darauf hin.
Dieser Server wendet die Korrektur an und liefert die Belege dafür, warum sie nötig ist.
Jede Antwort enthält die bekannten Fehler, die für diese Abfrage gelten, mit gemessenen Belegen und Herkunft der Verifikation.
Die kritische Korrektur ist angewendet, nicht nur angekündigt. Der Kanal air bedeutet bereits „auf einem Flughafen abgefertigte Luftfracht“. Der kontaminierte Block bleibt absichtlich als air_declared_at_port abfragbar — für alle, die ihn prüfen möchten.
Die Importdateien enthalten VL_FRETE und VL_SEGURO — Fracht und Versicherung, wie beim Zoll angegeben. Es ist das beste öffentlich verfügbare systematische Maß für realisierte Kosten, und fast niemand nutzt es.
China → Brasilien, Jan–Jul 2026, korrigiert:
Kanal | Gewicht (kg) | Fracht US$/kg | Fracht % vom FOB | Wertdichte |
Luft (am Flughafen abgefertigt) | 33.993.130 | 10,81 | 9,37 % | US$ 115,36/kg |
See | 16.074.641.185 | 0,142 | 5,68 % | US$ 2,51/kg |
Luftfracht kostet 76× mehr pro Kilogramm und nur 1,65× mehr pro Dollar Warenwert. Die Verkehrsträgeraufteilung dieses Korridors ist keine Frachtentscheidung — sondern eine Entscheidung über die Wertdichte.
Erfordert Node ≥ 22.5 (nutzt integriertes SQLite — null native Abhängigkeiten, kein node-gyp).
npm install && npm run build
npm run db:build -- --years 2025,2026 # fetches from the official source, builds SQLitedb:build lädt die Dateien direkt von balanca.economia.gov.br. Dieses Paket verteilt keine Daten weiter — die Datenbank wird auf Ihrem Rechner gebaut, immer frisch von der Quelle.
Tool | Funktion |
| Wert, Gewicht und Wertdichte nach Jahr, Monat, Land, HS-Code und Kanal. |
| Erklärte Fracht und Versicherung pro Kanal: US$/kg und % vom FOB. Nur Importe. |
| Die bekannten Fehler des Datensatzes, mit Belegen, Korrekturregel und Checkliste vor der Veröffentlichung. |
| Löst Land, HS-Code, Verkehrsträger und Zollstelle auf (mit Flughafen/Hafen-Klassifizierung). |
Die Aggregate wurden per Kreuzimplementierung validiert: Derselbe Ausschnitt, verarbeitet durch einen einzigen awk-Durchlauf über die rohe CSV und durch die SQL-View dieses Servers, ergibt bis zur letzten Ziffer identische Werte (349.250 Datensätze, 7 Kanäle, Fracht- und Gewichtswerte).
npm test # 12 tests covering the classification logic and the caveat registryMIT. Daten: Comex Stat, Brazilian Foreign Trade Secretariat / Federal Revenue Service. Autor: Luis Delfin
Defeitos conhecidos do dataset do Comex Stat, cada um com evidencia quantificada, regra de correcao e procedencia da verificacao. Use ANTES de publicar qualquer numero derivado desta fonte — inclui o checklist de conferencia. Esta tool responde a pergunta que um wrapper de dados nunca responde: este campo quer dizer o que parece?
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Um caveat especifico. Vazio = todos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It accurately describes a safe read-only behavior (retrieving caveat metadata) and discloses the internal structure of each result (evidence, correction rule, provenance). For a low-risk retrieval tool there is little behavioral hazard left uncovered.
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 front-loaded with purpose and usage, and the essential guidance fits in three sentences. The closing rhetorical question adds rhetorical color but no operational information, making it mildly less economical than it could be.
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 tool with one optional enum parameter and no output schema, the description is reasonably complete: it explains what the results contain, when to invoke it, and the overall QA intent. It does not specify the return format, but that is a minor gap for this information-retrieval use case.
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 100%: the single 'id' parameter carries an enum and a clear explanation ('Um caveat especifico. Vazio = todos.'), so the schema already documents the parameter. The description adds no additional parameter-level detail, matching the baseline for high coverage.
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 exposes known defects of the Comex Stat dataset, each with quantified evidence, a correction rule, and verification provenance. It positions itself against 'a data wrapper' generically, distinguishing its QA purpose from the sibling trade-flow/freight tools, though it never names those siblings explicitly.
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?
It gives explicit when-to-use guidance ('Use ANTES de publicar qualquer numero derivado desta fonte') and mentions a built-in conferencing checklist. However, it does not state when NOT to use it or name the alternatives (comex_trade_flow, comex_freight_cost) that it should be paired with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frete e seguro DECLARADOS a aduana, por canal de transporte — em US$/kg e como % do valor FOB. Vem dos campos VL_FRETE e VL_SEGURO dos arquivos de importacao, que os resumos publicados descartam: e a melhor medida sistematica de custo realizado disponivel publicamente. Somente importacao (os arquivos de exportacao nao trazem frete). O canal 'air' ja esta corrigido pelo ponto de despacho.
| Name | Required | Description | Default |
|---|---|---|---|
| ncm | No | NCM completo ou prefixo. | |
| years | No | Anos, ex: [2025, 2026]. | |
| months | No | Meses 1-12. Vazio = todos. | |
| group_by | No | Dimensoes extra (o canal ja entra sempre). | |
| countries | No | Codigo, nome ou ISO3 do pais de origem. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the data source (VL_FRETE and VL_SEGURO fields), the fact it is import-only, that air is corrected by despatch point, and the output units (US$/kg and % of FOB). It does not describe the response shape or potential limitations like missing data or aggregation behavior, but the key behavioral facts are present. A score of 4 reflects that the description goes beyond a bare statement of function.
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?
Three sentences, each earning its place: the first defines the product and units, the second explains provenance and why it is valuable, the third states constraints (import-only and air correction). It is front-loaded with the core definition and avoids redundant words. No fluff or repetition of schema content. This is concise and well-structured.
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?
The tool has 5 parameters, no output schema, and no annotations. The description effectively communicates what the tool provides, but it does not describe the return format (e.g., whether it returns a table per channel, time series, or aggregated values). Since there is no output schema, the agent is left guessing at the response structure. While the core semantics are clear, the agent may need additional guidance on what to expect, making it incomplete for a complex data tool.
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 100% for all 5 parameters, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; it mentions the channel is always included (which relates to group_by) but does not explain details like how NCM prefix matching works or how to combine years/months. The schema already describes each parameter clearly. Thus the description adds no extra value for parameter understanding.
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 names a specific resource (freight and insurance declared to customs by transport channel) and clearly distinguishes it from siblings by emphasizing it is the best systematic measure of realized cost. The verb is implicit ('provides') but the scope and source are explicit. It differentiates itself from comex_trade_flow (which likely covers flows) and comex_data_caveats (which explains caveats). This is a clear, distinct purpose.
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 gives a clear constraint: only imports, with export files lacking freight. It also states the air channel is corrected, which is a usage detail. It implies the tool should be used when realized cost is needed ('melhor medida sistematica de custo realizado'), but it does not explicitly name alternatives or say when not to use it. Thus it provides clear context and a condition, but stops short of explicit when-to-use vs. 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.
Resolve codigos oficiais para nomes e vice-versa: pais, NCM, modal de transporte (VIA) e unidade da Receita de despacho (URF, com sua classificacao aeroporto/porto/outra). Necessario porque o dataset e todo codificado.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Tipo de codigo. | |
| limit | No | Maximo de resultados (default 20). | |
| query | Yes | Codigo exato ou parte do nome. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It mentions bidirectional resolution and the URF classification, which adds specific context. However, it does not disclose return format, error handling, or whether partial matches are supported. For a simple lookup this is adequate but not comprehensive.
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 concise sentences. The first states the core function and lists the code types, the second provides the rationale. There is no wasted wording, and the key action is front-loaded.
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 (3 parameters, no output schema, no annotations), the description is essentially complete. It covers purpose, scope, and rationale. It could mention the return structure (e.g., list of matches) but the bidirectional resolver nature makes that non-critical for an agent to call it correctly.
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 100%, so the baseline is 3. The description adds value by explaining what each kind represents (e.g., VIA is modal de transporte, URF includes classification aeroporto/porto/outra) and clarifies that query can be a code or a name. This enriches the parameter semantics beyond the schema alone.
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 states a specific verb 'Resolve' with the resource 'codigos oficiais para nomes e vice-versa' and enumerates the exact code types (pais, NCM, VIA, URF) including URF's classification. This clearly distinguishes it from sibling tools like comex_trade_flow or comex_freight_cost, which handle completely different operations.
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 gives clear context: the dataset is all coded, so the tool should be used whenever codes need translating. While it doesn't explicitly state alternatives or when not to use it, the sibling tools are not viable alternatives for this function, so the lack of exclusion is acceptable. The rationale is enough for an agent to infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fluxo de comercio exterior do Brasil (valor, peso e densidade de valor) a partir dos microdados aduaneiros oficiais do Comex Stat. Filtra por ano, mes, pais, NCM e canal de transporte, e agrupa como pedido. O canal 'air' JA vem corrigido pelo ponto de despacho — o campo de modal do dataset e contaminado e nao pode ser usado cru. A resposta inclui sempre os caveats aplicaveis e a procedencia dos arquivos.
| Name | Required | Description | Default |
|---|---|---|---|
| ncm | No | NCM completo (8 digitos) ou prefixo, ex: '8517' ou '85'. | |
| flow | No | Sentido do fluxo. Default: import. | |
| limit | No | Maximo de linhas (default 50, max 500). | |
| years | No | Anos, ex: [2025, 2026]. | |
| months | No | Meses 1-12. Vazio = todos. | |
| channel | No | Canal corrigido. 'air' = modal aereo despachado em aeroporto. 'air_declared_at_port' expoe o bloco contaminado, para inspecao. | |
| group_by | No | Dimensoes de agrupamento. Default: ['year']. | |
| countries | No | Codigo, nome (PT/EN) ou ISO3. Ex: ['160'] ou ['China']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses significant behavioral details: the 'air' channel is corrected by dispatch point because the dataset's modal field is contaminated and should not be used raw, and the response always includes applicable caveats and file provenance. This is valuable transparency about data quality and output structure. It does not cover all typical behaviors (e.g., read-only nature, pagination, rate limits), but the critical data correction and output caveat information is highly informative.
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 concise, two sentences, and front-loaded with the main purpose. The first sentence states the core function, filters, and grouping; the second adds critical caveats about channel correction and response contents. There is no fluff, and the structure is efficient. It earns a 4 rather than 5 because it could be slightly more structured with bullets, but it is already clear and compact.
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 complexity of 8 parameters (all optional) and no output schema, the description covers key aspects: it specifies the metrics returned, the correction for the 'air' channel, and that responses always include caveats and file provenance. This is fairly complete for a data retrieval tool. However, it does not mention typical response format details (e.g., units, pagination, or whether results are aggregated by default), and it omits any prerequisites like authentication. These are minor gaps but not critical.
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 100%, so all 8 parameters already have explanatory text in the schema. The description text itself does not add new semantics for parameters beyond what the schema provides, even though the channel parameter's complex behavior is fully explained in the schema. According to the rubric, when schema coverage is high, the baseline is 3, and the description adds no additional value here.
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 Brazil foreign trade flow data (value, weight, and value density) from official Comex Stat microdata, including filters and grouping. It mentions the specific resource and the metrics returned, making the purpose evident. It lacks an explicit verb like 'retrieve' but the noun-based phrasing is still clear. It is distinguishable from siblings, which focus on freight, code resolution, and caveats.
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 does not mention when to use this tool versus the sibling tools (comex_data_caveats, comex_freight_cost, comex_resolve_code). It provides no explicit conditions for selecting this tool over alternatives, nor any 'when not to use' guidance. The only implicit hint is that it covers trade flows, but that is not sufficient for guiding tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0comex_data_caveatscomex_freight_costcomex_resolve_codecomex_trade_flowScored across 4 tools
The four tools have clearly distinct purposes: trade flow provides aggregated trade metrics, caveats explains data quality issues, freight cost focuses specifically on freight/insurance, and resolve_code handles code translation. There is no ambiguity in their scopes, and each tool addresses a separate aspect of working with the Comex Stat dataset.
All tools share the consistent 'comex_' prefix, which helps identify the server's domain. However, the naming patterns vary: three use noun phrases (trade_flow, data_caveats, freight_cost) while one uses a verb (resolve_code). This is a minor deviation, but the uniform prefix and clear terminology keep the set predictable.
With only four tools, the server is tightly scoped to the essential needs of querying Comex Stat data and understanding its caveats. Each tool is necessary and covers a distinct functional area, so the count is well-suited for the server's purpose without unnecessary bloat or trivial additions.
The tools cover the core workflows: querying trade flow, obtaining freight cost details, validating data quality through caveats, and resolving official codes. A minor gap is that freight data is only available for imports, but this is clearly stated and not a flaw in the tool design. Overall, the surface is sufficient for common analytical tasks.
Brazil Comex Stat MCP — Brazilian foreign trade statistics from MDIC (Ministério do…
UN Comtrade international trade statistics via MCP. Country/HS lookups, flows, balances, rankings.
AI-powered commodity price forecasts and Brazil trade intelligence via MCP. Access Brazilian exports and imports from MDIC/ComexStat since 2000, by HS4, HS6 and NCM code, partner country, USD FOB and kilograms — plus crop production, supply & demand, climate data and production forecasts for major commodities including soybeans, coffee, corn, beef and cocoa. Compare trade flows, markets, countries and time periods with like-for-like windows. Every answer identifies the measurement period and data source. 15 read-only tools. Metered in credits. Connect directly via Streamable HTTP — no installation required: https://mcp.kyrodata.com/mcp Authentication: Bearer key or OAuth 2.1 (PKCE). Official MCP registry: com.kyrodata/kyrodata
Trade Intel MCP — Compound tools that chain Comtrade, Census, Treasury,
