Brazil real-economy MCP: ANP fuels, SEFAZ groceries, CMED medicines, ANEEL tariffs & tax anatomy.
Scored across 12 tools
Each tool targets a distinct data domain (fuels, LPG, groceries, pharma, electricity tariffs, freight, taxes, cost of living, purchasing power), and descriptions include explicit 'When to use / When NOT to use' routing hints that point at the correct sibling tool. Mild overlap remains among the aggregating tools (brazil_cost_of_living, brazil_purchasing_power_oracle, brazil_grocery_basket) which all touch household expenditure, and brazil_compare_regions sits conceptually close to the single-state price tools, but the guidance resolves this.
All twelve tools use a uniform brazil_ snake_case prefix, giving a predictable namespace. The final segment mixes verb-led names (brazil_list_states, brazil_compare_regions) with noun phrases (brazil_fuel_prices, brazil_tax_anatomy, brazil_cost_of_living), and brazil_contract_intent_a2a introduces an unusual 'a2a' suffix, so it is not a pure verb_noun convention.
Twelve tools is well within a healthy range for a multi-domain Brazilian price oracle, with one tool per commodity/analytics family rather than redundant variants. Each tool covers a distinct dataset and none appears to be a near-duplicate padding the list.
The surface covers the core Brazilian consumer-price domains (fuel, LPG, grocery basket, medicines, electricity, freight, taxes, cost of living, purchasing power) plus discovery and cross-state comparison, so agents can complete most workflows. Gaps are minor: there is no city-level discovery tool (only brazil_list_states) despite city-level fuel and gas queries, and no historical/trend or time-series tool — everything is a current snapshot.
Calculates cross-state price differentials (percentage delta % and BRL spread) for inter-state freight routing and corporate procurement between an origin state and a destination state. When to use: Use ONLY when a user specifically needs a side-by-side comparative delta % or arbitrage spread between two different Brazilian states (e.g., SP vs RJ, MG vs PR). When NOT to use: Do NOT use to query prices of a single state (use brazil_fuel_prices, brazil_grocery_basket, or brazil_lpg_gas_prices). Read-only operation; no authentication required up to 60 req/min.
| Name | Required | Description | Default |
|---|---|---|---|
| categoria | No | Economic indicator category to compare: 'todos', 'combustiveis', 'gas_cozinha', 'cesta_basica'. Defaults to 'todos'. | todos |
| uf_origem | Yes | Origin two-letter Brazilian state code for comparison (e.g., 'sp', 'rj', 'ba'). Defaults to 'sp'. | sp |
| uf_destino | Yes | Destination two-letter Brazilian state code for comparison (e.g., 'mg', 'pr', 'sc', 'rj'). Defaults to 'rj'. | rj |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld and non-destructive. The description adds genuinely new operational context: no authentication required and a 60 req/min ceiling, which the agent cannot see elsewhere. It stops short of describing the shape of the returned comparison, which is the only remaining gap.
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?
Front-loaded with the core computation, then cleanly split into use / do-not-use blocks. Slightly dense in the first sentence, but each sentence carries weight and the example pairs aid selection.
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?
With no output schema, the description still tells the agent what comes back (percentage delta % and BRL spread). Combined with the routing guidance, rate limit, and auth note, an agent has everything needed to select and call this 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 all three parameters including the category enum are already documented. The description reinforces the origin/destination semantics and mentions example state pairs, but adds no syntax or behavioral detail beyond the schema. Baseline 3 applies.
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?
States a specific verb and resource — 'Calculates cross-state price differentials (percentage delta % and BRL spread)' — and scopes it to origin/destination state pairs. This is immediately distinguishable from siblings like brazil_cost_of_living or brazil_freight_logistics, which do not produce pairwise deltas.
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?
Explicit 'When to use' names the precise condition (side-by-side delta % or arbitrage spread between two different states) and 'When NOT to use' routes single-state queries to three named alternatives. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issues a cryptographically signed Machine-to-Machine (A2A) Economic Intent Protocol and settlement guarantee. Enables enterprise autonomous agents (fleet management bots, hospital procurement systems, wholesale supply coordinators) to formalize an intention to acquire fuels, basic food baskets, or regulated pharmaceutical supplies. The oracle verifies factual minimum prices against primary audited databases and generates a tamper-proof SHA-256 digital certificate issued by Holding Arthur Luis Vieira dos Santos, valid for 24 hours as an immutable settlement ceiling. When to use: Use when two autonomous agents need to negotiate and seal a formal procurement protocol with verifiable digital signature and settlement bounds. When NOT to use: Do NOT use for simple read-only price checks (use brazil_fuel_prices, brazil_grocery_basket, or brazil_pharma_medicines). Idempotent cryptographic certificate generation.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state code where procurement will take place (e.g., 'rj', 'sp', 'mg', 'ba', 'pe'). Defaults to 'rj'. | rj |
| cidade | No | Target Brazilian municipality or distribution hub (e.g., 'Cabo Frio', 'Sao Paulo', 'Recife', 'Rio de Janeiro'). Defaults to 'Cabo Frio'. | Cabo Frio |
| tipo_operacao | Yes | Economic procurement category for the machine intent contract: 'abastecimento_frota' (fleet refueling), 'cesta_basica_atacado' (wholesale food baskets), 'dispensacao_farmaceutica' (pharmaceutical supply), 'auditoria_tributaria' (tax audit certification). Defaults to 'abastecimento_frota'. | abastecimento_frota |
| item_especifico | No | Specific commodity code, fuel type (e.g., 'diesel_s10', 'gasolina'), or active pharmaceutical ingredient (e.g., 'losartana'). Defaults to 'diesel_s10'. | diesel_s10 |
| volume_estimado | No | Estimated procurement volume in liters (for fuels), units (for food baskets), or packages (for medicines). Defaults to 500. | |
| agente_solicitante_id | No | Unique identifier or public key of the requesting partner AI agent or automated fleet bot. Defaults to 'FleetBot-Logistica-01'. | FleetBot-Logistica-01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=true, destructive=false, but the description adds real substance beyond them: oracle verification against primary audited databases, a SHA-256 certificate, the issuing authority, and a 24-hour validity window as an immutable settlement ceiling. It does not explain error/failure behavior when the oracle cannot verify a price, and restates idempotency already in the annotations.
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?
Front-loaded with purpose and cleanly separated into use/do-not-use blocks, but padded with promotional language ('tamper-proof', 'immutable settlement ceiling', the full name of the issuing holding company) that does not help an agent decide or call the tool.
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 six-parameter write tool with no output schema, the description supplies the essentials: what is produced (a signed SHA-256 certificate), who issues it, and how long it stays valid. It stops short of describing the certificate's payload fields or how an agent later verifies/retrieves it, which is the remaining gap given there is no output schema.
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% with examples and defaults for all six parameters, so the schema carries the load. The description adds only category-level mapping (fuels, food baskets, pharmaceutical supplies) and omits the 'auditoria_tributaria' enum value entirely, so it adds no meaning beyond the schema.
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?
States a specific verb and resource ('Issues a cryptographically signed ... Economic Intent Protocol and settlement guarantee') and names the read-only price siblings it is not. The core framing is heavy on proprietary jargon ('Economic Intent Protocol'), but the following sentence about formalizing an intention to acquire fuels, food baskets or pharma supplies makes the actual function legible.
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?
Explicit 'When to use' (two autonomous agents negotiating a formal procurement protocol with verifiable signature and settlement bounds) and 'When NOT to use' with three named alternatives: brazil_fuel_prices, brazil_grocery_basket, brazil_pharma_medicines. This is exactly the routing information an agent needs against this sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the total estimated monthly household expenditure budget in Brazilian Reais (BRL) and USD across Brazilian states. Aggregates monthly food, baseline utilities, and standard domestic maintenance into a single consolidated currency figure. When to use: Use ONLY to retrieve the estimated total monthly financial expenditure in BRL or USD to live in a given state. When NOT to use: Do NOT use for labor-hour working time metrics (use brazil_purchasing_power_oracle), individual electricity tariffs (use brazil_energy_tariffs), or raw commodity prices (use brazil_fuel_prices or brazil_grocery_basket). Read-only operation; no authentication required up to 60 req/min.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state code (e.g., 'sp', 'rj', 'df', 'mg'). Defaults to 'sp'. | sp |
| converter_usd | No | When true, converts all BRL cost metrics into USD using live exchange rates. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the 'Read-only operation' phrase is largely redundant. However the description adds genuinely new context beyond annotations: no authentication required and a 60 req/min rate limit, plus what the aggregate is composed of (food, baseline utilities, domestic maintenance). It stops short of explaining exchange-rate sourcing for the USD conversion or whether figures assume a fixed household size.
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?
Purpose is front-loaded and the when/when-not structure is easy to parse. There is some redundancy: 'When to use: Use ONLY to retrieve the estimated total monthly financial expenditure' restates the opening sentence, and 'Read-only operation' repeats the annotations, but no sentence is harmful.
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 two-parameter read tool with no output schema, the description covers purpose, exclusions, what the number aggregates, and operational limits (auth-free, 60 req/min). Remaining gaps—household-size assumptions and USD conversion mechanics—are minor but real.
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 both 'uf' and 'converter_usd' are already documented with defaults and examples. The description only adds that USD uses live exchange rates, which is already in the schema; it adds no new constraint or format detail. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource ('Computes the total estimated monthly household expenditure budget in BRL and USD across Brazilian states') and even names the components aggregated. An agent can distinguish it from every sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' restricted scope (total monthly expenditure for a given state) plus a 'When NOT to use' list that routes four sibling tools to their correct purposes (purchasing power, energy tariffs, fuel prices, grocery basket). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides official ANEEL residential electricity tariffs (B1) across all 27 Brazilian states (UFs) and computes thermal cooking parity comparing 13kg LPG gas cylinder vs 99 kWh induction power. When to use: Use specifically to look up residential electric kWh rates, monthly electric bills, or thermal energy parity between gas and electric cooking. When NOT to use: Do NOT use for total household cost of living (use brazil_cost_of_living) or vehicle fuel prices (use brazil_fuel_prices). Read-only and idempotent operation; zero authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state acronym (e.g., 'rj', 'sp', 'mg', 'ba', 'df'). Defaults to 'rj'. | rj |
| consumo_kwh | No | Monthly electricity consumption in kWh for residential bill calculation. Defaults to standard baseline 150 kWh. | |
| calcular_paridade_termica | No | Whether to calculate thermal cooking parity comparing 13kg LPG cylinder vs 99 kWh induction cooking. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the description's 'Read-only and idempotent' sentence is largely repetition and earns little credit. The one genuinely additive piece is 'zero authentication required', which annotations do not cover, plus the implicit ANEEL source authority. No discussion of output shape or what the parity computation assumes, which matters since there is no output schema.
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 opening sentence is front-loaded with the core purpose, followed by clearly labelled use and non-use clauses. The trailing 'Read-only and idempotent operation' clause duplicates annotation data and is the one sentence that does not fully earn its place.
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?
With three simple params, full schema coverage and no output schema, the description covers what the tool does and when to reach for it. It stops short of stating what the returned bill/parity figures include (e.g. whether ANEEL tariffs embed taxes or surcharges), which is a meaningful gap for a numeric-lookup tool with no output schema.
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 schema already documents uf, consumo_kwh and calcular_paridade_termica including defaults, giving a baseline of 3. The description adds only the fixed constants used in parity (13kg cylinder, 99 kWh induction), which is useful but does not clarify parameter behavior beyond the schema.
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?
States specific verbs and resources: looks up official ANEEL residential B1 tariffs across all 27 UFs and computes thermal cooking parity (13kg LPG vs 99 kWh induction). The scope and the two distinct outputs are unambiguous, and it is clearly separable from siblings like brazil_lpg_gas_prices or brazil_cost_of_living.
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?
Provides an explicit 'When to use' list (kWh rates, monthly bills, gas-vs-electric parity) and an explicit 'When NOT to use' list routing to brazil_cost_of_living and brazil_fuel_prices by name. This is the strongest form of routing guidance: both inclusion and exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates official Brazilian minimum road freight rates regulated by ANTT (Agencia Nacional de Transportes Terrestres - Resolution No. 5,867/2020) across all vehicle classes (2 to 9 axles) and cargo types (solid bulk, general cargo, refrigerated). Correlates freight costs with ANP Diesel S10 pump prices, computing diesel fuel expense ratio and the logistical cost impact per kilogram of food transported. When to use: Calculate official ANTT freight rates, diesel expense ratio, or transport logistics costs between Brazilian cities. When NOT to use: Do NOT use for retail diesel pump prices at local gas stations (use brazil_fuel_prices). Read-only and idempotent operation; zero authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| uf_origem | No | Origin state code (e.g., 'sp', 'rj', 'mg') for diesel price correlation. Defaults to 'sp'. | sp |
| tipo_carga | No | ANTT cargo classification type. Defaults to 'geral'. | geral |
| uf_destino | No | Two-letter Brazilian state acronym for destination (e.g., 'rj', 'sp', 'mg', 'ba'). Defaults to 'rj'. | rj |
| distancia_km | Yes | Total road route distance in kilometers (e.g., 430 for SP-RJ corridor). Defaults to 100 km. | |
| numero_eixos | No | Number of vehicle axles: 2 (Toco 8t), 3 (Truck 14t), 4 (Cavalo Toco 22t), 5 (Carreta 27t), 6 (Carreta 32t), 7 (Bitrem 38t), 9 (Rodotrem 50t). Defaults to 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, and the description avoids repeating them wholesale while adding that zero authentication is required — context not present in the annotations. It also discloses the regulatory basis (Resolution 5,867/2020) and the correlation behavior with ANP Diesel S10 prices. It does not describe the shape of the computed result, which leaves a modest gap.
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?
Front-loaded with the core computation before the usage rules, and every sentence carries information (scope, regulatory source, usage routing, safety profile). Slightly dense with the parenthetical agency expansion, but no padding.
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?
With no output schema, the description does carry the burden of return-value disclosure, and it names the outputs it computes (freight rate, diesel fuel expense ratio, cost impact per kg). This is enough for an agent to know what to expect, though the exact result fields and units are not enumerated.
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 parameters are already fully documented including enums and defaults, making 3 the baseline. The description restates axle range (2-9) and cargo categories that already exist in the schema, and only lightly signals that origin/destination states drive the diesel price correlation.
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?
States a specific verb and resource ('Calculates official Brazilian minimum road freight rates regulated by ANTT') and scopes it precisely to vehicle classes and cargo types. This is clearly separable from every sibling, and it explicitly names brazil_fuel_prices as the tool it is not.
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?
Contains an explicit 'When to use' clause listing the three computations (ANTT rates, diesel expense ratio, logistics costs between cities) and a 'When NOT to use' clause routing retail diesel queries to brazil_fuel_prices. Both the positive and negative conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries real-time audited retail fuel prices across all 27 Brazilian Federative Units (UFs) and 417+ cities from Brazil's National Petroleum Agency (ANP). Covers Regular Gasoline (Gasolina Comum), Additive Gasoline (Gasolina Aditivada), Hydrous Ethanol (Etanol Hidratado), Diesel S10, Diesel S500, and CNG (GNV). Calculates official 70% biofuel economic parity ratio and price dispersion across 5,939 monitored gas stations across all 27 Brazilian states (official ANP weekly audited sample). When to use: Retrieve current station-level and statewide retail fuel prices and ethanol vs gasoline parity in Brazil. When NOT to use: Do NOT use for residential cooking gas LPG prices (use brazil_lpg_gas_prices) or freight transport rates (use brazil_freight_logistics). Read-only and idempotent operation; no authentication required up to 60 req/min.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df'). Call brazil_list_states to see all 27 valid UF codes. | sp |
| cidade | No | Optional city name or URL slug (e.g., 'sao-paulo', 'rio-de-janeiro', 'campinas', 'salvador'). Defaults to empty string to return statewide statistics. | |
| combustivel | No | Fuel type filter for price ranking and statistics. Defaults to 'todos'. | todos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces rather than contradicts them while adding genuinely new operational facts: no authentication required and a 60 req/min rate limit. It also discloses data provenance and freshness ('official ANP weekly audited sample'), which matters for interpreting results. It stops short of describing failure behavior for invalid UF/city or the shape of the returned statistics, keeping it below a 5.
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 key scoping and the when/when-not guidance are front-loaded, which is good, but there is real redundancy: 'all 27 Brazilian Federative Units (UFs)' is restated as 'all 27 Brazilian states', and the fuel list appears twice in effect. The station count (5,939) is a marketing flourish that does not help an agent invoke the tool correctly.
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?
With no output schema, the description must carry the burden of what comes back, and it does reasonably well by naming the computed outputs (70% biofuel parity ratio, price dispersion, price ranking) alongside the raw prices. Coverage of expected result fields is indicative rather than explicit, so it falls just short of complete.
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%, and each parameter already documents its format, defaults, an enum, and even points to brazil_list_states for valid UF codes. The description adds no parameter-level syntax or format detail beyond that, so the baseline of 3 applies.
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 opens with a specific verb and resource ('Queries real-time audited retail fuel prices') and scopes it to Brazil's ANP data across UFs and cities. It enumerates the exact fuel types covered and names the sibling tools it is not (brazil_lpg_gas_prices, brazil_freight_logistics), so an agent can distinguish it without reading any schema.
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 has explicit 'When to use' and 'When NOT to use' clauses, and the exclusion clause routes to the correct alternatives by name with the distinguishing subject matter (LPG, freight). This is exactly the when/when-not/alternatives structure that earns top marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries real-time audited supermarket prices of Brazil's 13 Basic Food Basket items (rice, beans, coffee, soybean oil, milk, sugar, beef, french bread, butter, flour, tomato, banana, potato) sourced from electronic consumer invoices (NFC-e SEFAZ) and DIEESE methodology across 59 regional hubs. When to use: Look up staple grocery prices, item-level supermarket quotes, and food basket totals. When NOT to use: Do NOT use for broad cost-of-living index synthesis (use brazil_cost_of_living) or minimum-wage labor hours (use brazil_purchasing_power_oracle). Read-only and idempotent operation; no authentication required up to 60 req/min.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pe', 'rs'). Defaults to 'sp'. | sp |
| cidade | No | Optional Brazilian city name or slug to filter local supermarket chains. Defaults to empty string to return statewide summary. | |
| produto | No | Optional food item filter (e.g., 'arroz', 'feijao', 'cafe', 'leite', 'oleo_soja', 'carne', 'pao_frances', 'cesta_basica'). Defaults to 'cesta_basica'. | cesta_basica |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the description's restatement of 'read-only and idempotent' adds nothing. It does add genuinely new context: no authentication and a 60 req/min rate limit, plus the invoice/methodology provenance. With the behavior profile otherwise fully covered by annotations, this lands above baseline but not at the top.
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?
Front-loaded with the core capability, then usage guidance, then constraints; every section is purposeful. Slight redundancy in re-listing the 13 items that the produto parameter description partially restates, and 'read-only and idempotent' duplicates the annotations.
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 3-parameter, fully documented, annotated read-only tool with no output schema, the description covers provenance, coverage, rate limits and sibling exclusions. The only gap is what the response actually contains (per-item breakdown vs. basket total shape), which an agent must infer.
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%, with uf, cidade and produto each documented including defaults and examples, so the structured data already carries parameter meaning. The description only gestures at item-level vs. basket-total filtering ('the 13 Basic Food Basket items'), adding no syntax or format detail beyond the schema. Baseline 3 applies.
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?
States a specific verb (queries) and resource (real-time audited supermarket prices for Brazil's 13 Basic Food Basket items), enumerates the items, names the data sources (NFC-e SEFAZ, DIEESE) and the 59-hub scope. This is clearly distinguishable from siblings like brazil_fuel_prices or brazil_cost_of_living.
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?
Explicit 'When to use' (staple grocery prices, item-level quotes, basket totals) and 'When NOT to use' with named alternatives (brazil_cost_of_living for index synthesis, brazil_purchasing_power_oracle for labor hours). Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discovery and metadata support tool: Returns the complete list of all 27 Brazilian Federative Units (UFs) covered by the server, including state code, state name, geographic macro-region, monitored gas station count, regional ICMS tax bracket, and dataset audit timestamp. When to use: Call this tool first to discover and validate state codes (uf) before invoking brazil_fuel_prices, brazil_grocery_basket, brazil_lpg_gas_prices, or brazil_compare_regions. When NOT to use: Do NOT use to get actual commodity prices (use domain-specific tools like brazil_fuel_prices). Read-only and idempotent; requires no parameters and no authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered; the description still adds that no parameters or authentication are required and that the response includes an audit timestamp. It does not describe ordering or pagination, but for a fixed 27-item list that is minor.
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?
Front-loaded purpose sentence followed by clearly labeled use / do-not-use clauses; every sentence maps to a decision the agent must make. The first sentence is long because it enumerates six returned fields, which is justified but slightly dense.
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?
With no input parameters and no output schema, the description compensates by enumerating the returned fields (state code, name, macro-region, station count, ICMS bracket, audit timestamp) and by stating prerequisites and auth needs. An agent has everything needed to call it correctly and interpret the result.
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 tool takes zero parameters and the description states that explicitly, so there is no parameter semantics to document. The schema is empty and fully consistent, making the baseline score appropriate.
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?
Names a specific verb and resource ('Returns the complete list of all 27 Brazilian Federative Units') and enumerates the payload fields. It explicitly distinguishes itself from the price-oriented siblings, so an agent can separate it from brazil_fuel_prices or brazil_compare_regions without opening any schema.
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?
Contains explicit 'When to use' (validate uf codes first, before four named tools) and 'When NOT to use' (not for actual commodity prices) sections with named alternatives. Both the selection condition and the exclusion are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries official audited retail prices of residential cooking gas (13kg LPG cylinder / Botijao de Gas GLP P13) sourced from Brazil's National Petroleum Agency (ANP) across 13,145+ authorized resellers in all 27 Brazilian states. Updated weekly with distributor markups and regional dispersion. When to use: Look up residential 13kg cooking gas prices by state or city in Brazil. When NOT to use: Do NOT use for vehicle fuels such as gasoline, ethanol, or CNG (use brazil_fuel_prices) or electricity tariffs (use brazil_energy_tariffs). Read-only and idempotent operation; no authentication required up to 60 req/min.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df'). Defaults to 'sp'. | sp |
| cidade | No | Optional Brazilian city name or slug to filter local LPG resellers (e.g., 'sao-paulo', 'cabo-frio', 'recife'). Defaults to empty string to return statewide statistics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description still adds real value: rate limit ('60 req/min'), 'no authentication required', and data freshness ('updated weekly'). It does not describe the shape of the returned statistics (statewide vs city), but with annotations and a complete schema that gap is minor.
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?
Front-loaded with purpose, then cleanly segmented into when-to-use and when-not-to-use blocks; nearly every clause carries routing or scope information. Slightly padded by promotional scope numbers ('13,145+', 'all 27 states') and a vague 'regional dispersion' phrase, but no sentence is wasted overall.
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 2-parameter read-only lookup with 100% schema coverage, rich annotations, and no output schema, the description covers purpose, scope, routing, freshness, rate limits, and auth. Nothing an agent needs 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'uf' and 'cidade' are already fully documented with defaults and examples. The description only restates the filtering dimension ('by state or city') without adding format or constraint detail, so the baseline 3 applies.
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?
States a specific verb ('Queries') plus a precisely scoped resource ('official audited retail prices of residential cooking gas / 13kg LPG cylinder') with its data source (ANP) and coverage (13,145+ resellers, 27 states). It also explicitly excludes adjacent resources, so an agent can immediately distinguish it from brazil_fuel_prices and brazil_energy_tariffs.
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?
Contains explicit 'When to use' and 'When NOT to use' sections that name the correct alternative sibling for each excluded case (vehicle fuels → brazil_fuel_prices; electricity → brazil_energy_tariffs). No inference is required to route between this and its closest siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries official Maximum Consumer Prices (PMC) and Factory Prices (PF) for 26,635+ regulated medicines in Brazil from CMED/ANVISA, including state-specific ICMS tax brackets (18% to 20%), active ingredients, laboratory, presentation, and 100% free dispensing eligibility under the federal Farmacia Popular program (PFPB). When to use: Look up official regulated medicine ceiling prices (PMC), verify generic active ingredient equivalence, or check free dispensing status under Farmacia Popular across Brazilian states. When NOT to use: Do NOT use for supermarket personal care products (use brazil_grocery_basket) or non-pharmaceutical price queries. Read-only and idempotent operation; no authentication required up to 60 req/min (returns up to 15 matching presentations per call).
| Name | Required | Description | Default |
|---|---|---|---|
| uf | No | Two-letter Brazilian state code (e.g., 'sp', 'rj', 'mg', 'ba') to apply accurate regional ICMS tax bracket. Defaults to 'sp'. | sp |
| busca | Yes | Commercial brand name or active pharmaceutical ingredient in Portuguese (e.g., 'dipirona', 'losartana', 'metformina', 'insulina', 'amoxicilina', 'paracetamol'). Defaults to 'losartana'. | losartana |
| categoria | No | Regulatory medicine category filter: 'todos' (all regulated CMED entries), 'farmacia_popular' (100% free SUS program medicines), 'genericos' (bioequivalent generics), 'referencia' (innovator reference drugs), 'similares' (similar branded drugs). Defaults to 'todos'. | todos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the description's 'read-only and idempotent' line is redundant. It does add genuinely new behavior beyond the annotations: a 60 req/min rate limit, no auth requirement, and a cap of 15 presentations per call. That is real added context, but the repetition of annotation-backed traits and lack of failure-mode detail keep it at a 3.
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?
Front-loaded with what the tool returns and structurally organized into use / do-not-use / operational constraints. It is dense but the length is largely earned; minor redundancy in restating PMC and Farmacia Popular twice prevents a 5.
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?
With no output schema and only three parameters, the description covers the missing pieces: the result cap of 15 presentations, the fields returned (ingredient, lab, presentation), state-dependent tax variation, and rate limits. An agent has enough to call it correctly and set expectations on response size.
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 three parameters are already documented with defaults and an enum for categoria. The description only adds indirect hints (the 18%–20% ICMS range tied to uf, free-dispensing tied to farmacia_popular) rather than syntax or edge-case guidance, so baseline 3 applies.
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?
States a specific verb (queries) and resources (PMC and PF prices for 26,635+ CMED/ANVISA-regulated medicines), and enumerates the returned facets (ICMS brackets, active ingredients, laboratory, presentation, Farmacia Popular eligibility). It explicitly distances itself from brazil_grocery_basket, so an agent can separate it from siblings without opening a schema.
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?
Contains dedicated 'When to use' and 'When NOT to use' clauses with the specific alternative named for the wrong case (brazil_grocery_basket) plus a general exclusion for non-pharmaceutical queries. The selection condition is fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates monthly labor hours required under Brazilian standard CLT workload (220 hours) to afford basic survival items at federal minimum wage. Focuses strictly on time-to-earn labor metrics across Brazilian states (UFs). When to use: Use ONLY when asking how many hours or days of work at minimum wage are required to afford essential goods. When NOT to use: Do NOT use for currency-denominated total household budgets in BRL/USD (use brazil_cost_of_living), electricity tariffs (use brazil_energy_tariffs), or individual item prices (use brazil_grocery_basket or brazil_fuel_prices). Read-only and idempotent operation; zero authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state acronym (e.g., 'rj', 'sp', 'mg', 'ba', 'df'). Defaults to 'rj'. | rj |
| salario_base | No | Monthly income in BRL to calculate labor hours against standard 220h CLT workload. Defaults to official 2026 federal minimum wage (1621.00 BRL - Decree 12,797/2025). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only and idempotent operation; zero authentication required,' which the annotations already declare, so that adds no new information. It does add useful domain framing — CLT 220-hour workload and strict focus on labor-time metrics — but it does not describe the return shape (e.g., hours per item versus hours aggregated) or any limitations on the calculation.
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?
Front-loads the core purpose, then layers on scope, exclusions, and behavioral notes. Slightly verbose — 'across Brazilian states (UFs)' and the read-only sentence are somewhat redundant against the annotations — but no sentence is wasted.
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 two-parameter read-only tool with no output schema, the description gives enough context to call it correctly: the metric definition, geographic scope, and the sibling tools to avoid. The remaining gap is that it doesn't clarify what the returned labor-hours metric looks like, but that is minor for this complexity level.
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 both parameters are already fully documented, and the description adds only the calculation basis (220-hour CLT workload, federal minimum wage) that contextualizes them. Baseline 3 is correct when the schema already carries the parameter semantics.
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?
States a specific verb and resource: calculates monthly labor hours under CLT 220h at federal minimum wage, scoped strictly to Brazilian states. This is concrete enough that an agent can distinguish it from currency-denominated budget tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines the use case (how many hours/days of work at minimum wage to afford essential goods) and lists when NOT to use it, naming the exact sibling alternatives for budgets, energy tariffs, grocery baskets, and fuel prices. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details the anatomy of indirect consumption taxes in Brazil across all 27 states (UFs), covering single-phase ICMS (ad rem fixed per unit under CONFAZ Agreements 15/2023 and 199/2022 for fuels and LPG), standard ad valorem ICMS (17% to 22%), federal PIS/COFINS, and CIDE. Demonstrates the price formation cascade and federal tax reform (EC 132/2023 - IBS/CBS) transition impacts. When to use: Analyze fiscal burden, tax breakdown, and government revenue share in Brazilian consumer prices. When NOT to use: Do NOT use for basic price lookups without tax breakdown (use domain tools like brazil_fuel_prices). Read-only and idempotent operation; zero authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Two-letter Brazilian state acronym (e.g., 'sp', 'rj', 'mg', 'ba', 'df'). Defaults to 'sp'. | sp |
| categoria | No | Category to analyze tax anatomy: 'todos', 'combustiveis', 'gas_cozinha', 'cesta_basica', 'medicamentos'. Defaults to 'todos'. | todos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by stating zero authentication required and by characterizing the analytical output (price formation cascade, reform transition impacts). It does repeat read-only/idempotent, which annotations already declare, so it's not fully additive, but the auth note and output characterization are genuinely useful.
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?
Front-loaded with the core capability and tightly organized with explicit use/not-use clauses. Slightly padded by restating read-only/idempotent hints already present in annotations, but no sentence is wasted overall.
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?
Two fully documented parameters, no output schema needed, and the description conveys scope, tax components, and analytical intent. It could say more about the shape of the returned breakdown, but for a read-only analytical tool the coverage is sufficient.
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% and both parameters are well documented with an enum and default, so the baseline is 3. The description adds some semantic linkage by naming fuels, LPG, and categories that map to the enum values, but it never addresses uf or categoria directly.
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?
States a specific resource (indirect consumption tax anatomy across all 27 UFs) and enumerates the exact tax components covered: single-phase ad rem ICMS under CONFAZ 15/2023 and 199/2022, ad valorem ICMS 17-22%, PIS/COFINS, CIDE, plus price cascades and EC 132/2023 IBS/CBS reform. An agent can distinguish it from brazil_fuel_prices 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (analyze fiscal burden, tax breakdown, government revenue share) and when NOT to use (basic price lookups), naming the sibling brazil_fuel_prices as the alternative. Nothing is left to inference.
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.
brazil_purchasing_power_oracle2 fields changedInput schema / properties / salario_base / defaultPrevious value: -1518New value: +1621Input schema / properties / salario_base / descriptionPrevious value: -"Monthly income in BRL to calculate labor hours against standard 220h CLT workload. Defaults to federal minimum wage (1518.00 BRL)."New value: +"Monthly income in BRL to calculate labor hours against standard 220h CLT workload. Defaults to official 2026 federal minimum wage (1621.00 BRL - Decree 12,797/2025)."brazil_freight_logistics2 fields changedInput schema / properties / numero_eixos / descriptionPrevious value: -"Vehicle axle configuration (2=truck, 3=heavy truck, 5=semi-trailer, 6=trailer, 7=bitrem, 9=rodotrem). Defaults to 3."New value: +"Number of vehicle axles: 2 (Toco 8t), 3 (Truck 14t), 4 (Cavalo Toco 22t), 5 (Carreta 27t), 6 (Carreta 32t), 7 (Bitrem 38t), 9 (Rodotrem 50t). Defaults to 5."Input schema / properties / uf_destinoAdded value: +{
+ "default": "rj",
+ "description": "Two-letter Brazilian state acronym for destination (e.g., 'rj', 'sp', 'mg', 'ba'). Defaults to 'rj'.",
+ "type": "string"
+}brazil_compare_regions7 fields changedInput schema / properties / categoriaAdded value: +{
+ "default": "todos",
+ "description": "Economic indicator category to compare: 'todos', 'combustiveis', 'gas_cozinha', 'cesta_basica'. Defaults to 'todos'.",
+ "enum": [
+ "todos",
+ "combustiveis",
+ "gas_cozinha",
+ "cesta_basica"
+ ],
+ "type": "string"
+}Input schema / properties / destino_ufRemoved value: -{
- "description": "Destination two-letter Brazilian state code for comparison (e.g., 'mg', 'pr', 'sc').",
- "type": "string"
-}Input schema / properties / indicadorRemoved value: -{
- "description": "Economic indicator category to compare (default: 'todos').",
- "enum": [
- "combustiveis",
- "gas",
- "todos"
- ],
- "type": "string"
-}Input schema / properties / origem_ufRemoved value: -{
- "description": "Origin two-letter Brazilian state code for comparison (e.g., 'sp', 'rj', 'ba').",
- "type": "string"
-}Input schema / properties / uf_destinoAdded value: +{
+ "default": "rj",
+ "description": "Destination two-letter Brazilian state code for comparison (e.g., 'mg', 'pr', 'sc', 'rj'). Defaults to 'rj'.",
+ "type": "string"
+}Input schema / properties / uf_origemAdded value: +{
+ "default": "sp",
+ "description": "Origin two-letter Brazilian state code for comparison (e.g., 'sp', 'rj', 'ba'). Defaults to 'sp'.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "origem_uf",
- "destino_uf"
-]New value: +[
+ "uf_origem",
+ "uf_destino"
+]brazil_contract_intent_a2abrazil_cost_of_living5 fields changedInput schema / properties / comparar_com_dolarRemoved value: -{
- "description": "When true, converts all BRL cost metrics into USD using live exchange rates.",
- "type": "boolean"
-}Input schema / properties / converter_usdAdded value: +{
+ "default": false,
+ "description": "When true, converts all BRL cost metrics into USD using live exchange rates. Defaults to false.",
+ "type": "boolean"
+}Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'df'). Defaults to national average if omitted."New value: +"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'df', 'mg'). Defaults to 'sp'."Input schema / requiredAdded value: +[
+ "uf"
+]brazil_energy_tariffs7 fields changedInput schema / properties / calcular_paridade_termicaAdded value: +{
+ "default": true,
+ "description": "Whether to calculate thermal cooking parity comparing 13kg LPG cylinder vs 99 kWh induction cooking. Defaults to true.",
+ "type": "boolean"
+}Input schema / properties / consumo_kwhAdded value: +{
+ "default": 150,
+ "description": "Monthly electricity consumption in kWh for residential bill calculation. Defaults to standard baseline 150 kWh.",
+ "type": "number"
+}Input schema / properties / consumo_mensal_kwhRemoved value: -{
- "description": "Monthly electricity consumption in kWh for residential bill calculation. Defaults to standard baseline 150 kWh if omitted.",
- "type": "number"
-}Input schema / properties / incluir_paridade_termica_gasRemoved value: -{
- "description": "Whether to calculate thermal cooking parity comparing 13kg LPG cylinder vs 99 kWh induction cooking. Defaults to true.",
- "type": "boolean"
-}Input schema / properties / uf / defaultAdded value: +"rj"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state acronym (e.g. 'RJ', 'SP', 'MG', 'BA', 'DF'). Defaults to 'RJ' if omitted."New value: +"Two-letter Brazilian state acronym (e.g., 'rj', 'sp', 'mg', 'ba', 'df'). Defaults to 'rj'."Input schema / requiredAdded value: +[
+ "uf"
+]brazil_freight_logistics11 fields changedInput schema / properties / distancia_km / defaultAdded value: +100Input schema / properties / distancia_km / descriptionPrevious value: -"Highway route distance in kilometers. Defaults to 450 km (e.g. SP-RJ axis or regional agricultural corridor) if omitted."New value: +"Total road route distance in kilometers (e.g., 430 for SP-RJ corridor). Defaults to 100 km."Input schema / properties / numero_eixosAdded value: +{
+ "default": 3,
+ "description": "Vehicle axle configuration (2=truck, 3=heavy truck, 5=semi-trailer, 6=trailer, 7=bitrem, 9=rodotrem). Defaults to 3.",
+ "enum": [
+ 2,
+ 3,
+ 4,
+ 5,
+ 6,
+ 7,
+ 9
+ ],
+ "type": "integer"
+}Input schema / properties / tipo_carga / defaultAdded value: +"geral"Input schema / properties / tipo_carga / descriptionPrevious value: -"Cargo classification per ANTT: 'granel_solido' (grains/staples), 'carga_geral' (packaged groceries), 'frigorificada' (meats/dairy). Defaults to 'granel_solido'."New value: +"ANTT cargo classification type. Defaults to 'geral'."Input schema / properties / tipo_carga / enumPrevious value: -[
- "granel_solido",
- "carga_geral",
- "frigorificada",
- "perigosa"
-]New value: +[
+ "geral",
+ "granel_solido",
+ "granel_liquido",
+ "frigorificada",
+ "perigosa"
+]Input schema / properties / tipo_veiculoRemoved value: -{
- "description": "Truck axle configuration: 'carreta_5_eixos' (standard 27t), 'truck_3_eixos' (14t), 'bitrem_7_eixos' (38t), or 'rodotrem_9_eixos' (50t grain hauler). Defaults to 'carreta_5_eixos'.",
- "enum": [
- "toce_2_eixos",
- "truck_3_eixos",
- "cavalo_toco_4_eixos",
- "carreta_5_eixos",
- "bitrem_7_eixos",
- "rodotrem_9_eixos"
- ],
- "type": "string"
-}Input schema / properties / uf_destinoRemoved value: -{
- "description": "Two-letter state acronym of cargo destination (e.g. 'RJ', 'SP', 'BA'). Defaults to 'RJ'.",
- "type": "string"
-}Input schema / properties / uf_origem / defaultAdded value: +"sp"Input schema / properties / uf_origem / descriptionPrevious value: -"Two-letter state acronym of cargo origin (e.g. 'MT', 'PR', 'SP'). Defaults to 'SP'."New value: +"Origin state code (e.g., 'sp', 'rj', 'mg') for diesel price correlation. Defaults to 'sp'."Input schema / requiredAdded value: +[
+ "distancia_km"
+]brazil_fuel_prices7 fields changedInput schema / properties / cidade / defaultAdded value: +""Input schema / properties / cidade / descriptionPrevious value: -"Optional city name or URL slug (e.g., 'sao-paulo', 'rio-de-janeiro', 'cabo-frio', 'curitiba'). Omit to retrieve statewide summary."New value: +"Optional city name or URL slug (e.g., 'sao-paulo', 'rio-de-janeiro', 'campinas', 'salvador'). Defaults to empty string to return statewide statistics."Input schema / properties / combustivel / defaultAdded value: +"todos"Input schema / properties / combustivel / descriptionPrevious value: -"Fuel type filter for price ranking (default: 'todos')."New value: +"Fuel type filter for price ranking and statistics. Defaults to 'todos'."Input schema / properties / combustivel / enumPrevious value: -[
- "gasolina",
- "etanol",
- "diesel",
- "gnv",
- "todos"
-]New value: +[
+ "todos",
+ "gasolina",
+ "gasolina_aditivada",
+ "etanol",
+ "diesel_s10",
+ "diesel_s500",
+ "gnv"
+]Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df'). Call brazil_list_states for all 27 valid UF codes."New value: +"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df'). Call brazil_list_states to see all 27 valid UF codes."brazil_grocery_basket6 fields changedInput schema / properties / cidade / defaultAdded value: +""Input schema / properties / cidade / descriptionPrevious value: -"Optional Brazilian city name or slug to filter local supermarket offers."New value: +"Optional Brazilian city name or slug to filter local supermarket chains. Defaults to empty string to return statewide summary."Input schema / properties / produto / defaultAdded value: +"cesta_basica"Input schema / properties / produto / descriptionPrevious value: -"Optional product search term (e.g., 'arroz', 'feijao', 'cafe', 'leite', 'cesta basica')."New value: +"Optional food item filter (e.g., 'arroz', 'feijao', 'cafe', 'leite', 'oleo_soja', 'carne', 'pao_frances', 'cesta_basica'). Defaults to 'cesta_basica'."Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'mg', 'ba')."New value: +"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pe', 'rs'). Defaults to 'sp'."brazil_lpg_gas_prices4 fields changedInput schema / properties / cidade / defaultAdded value: +""Input schema / properties / cidade / descriptionPrevious value: -"Optional Brazilian city name to filter local LPG resellers."New value: +"Optional Brazilian city name or slug to filter local LPG resellers (e.g., 'sao-paulo', 'cabo-frio', 'recife'). Defaults to empty string to return statewide statistics."Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df')."New value: +"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'ce', 'df'). Defaults to 'sp'."brazil_pharma_medicines7 fields changedInput schema / properties / buscaAdded value: +{
+ "default": "losartana",
+ "description": "Commercial brand name or active pharmaceutical ingredient in Portuguese (e.g., 'dipirona', 'losartana', 'metformina', 'insulina', 'amoxicilina', 'paracetamol'). Defaults to 'losartana'.",
+ "type": "string"
+}Input schema / properties / categoriaAdded value: +{
+ "default": "todos",
+ "description": "Regulatory medicine category filter: 'todos' (all regulated CMED entries), 'farmacia_popular' (100% free SUS program medicines), 'genericos' (bioequivalent generics), 'referencia' (innovator reference drugs), 'similares' (similar branded drugs). Defaults to 'todos'.",
+ "enum": [
+ "todos",
+ "farmacia_popular",
+ "genericos",
+ "referencia",
+ "similares"
+ ],
+ "type": "string"
+}Input schema / properties / termoRemoved value: -{
- "description": "Commercial brand name or active ingredient in Portuguese (e.g., 'dipirona', 'losartana', 'ozempic', 'amoxicilina', 'paracetamol').",
- "type": "string"
-}Input schema / properties / tipoRemoved value: -{
- "description": "Regulatory category filter (default: 'todos').",
- "enum": [
- "todos",
- "generico",
- "novo",
- "similar",
- "biologico"
- ],
- "type": "string"
-}Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'mg') to apply accurate regional ICMS tax rate (default: 'sp')."New value: +"Two-letter Brazilian state code (e.g., 'sp', 'rj', 'mg', 'ba') to apply accurate regional ICMS tax bracket. Defaults to 'sp'."Input schema / requiredPrevious value: -[
- "termo"
-]New value: +[
+ "busca"
+]brazil_purchasing_power_oracle5 fields changedInput schema / properties / salario_baseAdded value: +{
+ "default": 1518,
+ "description": "Monthly income in BRL to calculate labor hours against standard 220h CLT workload. Defaults to federal minimum wage (1518.00 BRL).",
+ "type": "number"
+}Input schema / properties / salario_mensal_brlRemoved value: -{
- "description": "Monthly income in BRL to calculate labor hours against standard 220h CLT workload. Defaults to federal minimum wage (1518.00 BRL) if omitted.",
- "type": "number"
-}Input schema / properties / uf / defaultAdded value: +"rj"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state acronym (e.g. 'RJ', 'SP', 'MG', 'BA', 'DF'). Defaults to 'RJ' if omitted."New value: +"Two-letter Brazilian state acronym (e.g., 'rj', 'sp', 'mg', 'ba', 'df'). Defaults to 'rj'."Input schema / requiredAdded value: +[
+ "uf"
+]brazil_tax_anatomy4 fields changedInput schema / properties / categoria / defaultAdded value: +"todos"Input schema / properties / uf / defaultAdded value: +"sp"Input schema / properties / uf / descriptionPrevious value: -"Two-letter Brazilian state acronym (e.g. 'RJ', 'SP', 'MG', 'BA', 'DF'). Defaults to 'RJ' if omitted."New value: +"Two-letter Brazilian state acronym (e.g., 'sp', 'rj', 'mg', 'ba', 'df'). Defaults to 'sp'."Input schema / requiredAdded value: +[
+ "uf"
+]emitir_contrato_intencao_a2aemitir_contrato_intencao_a2abrazil_compare_regionsbrazil_cost_of_livingbrazil_energy_tariffsbrazil_freight_logisticsbrazil_fuel_pricesbrazil_grocery_basketbrazil_list_statesbrazil_lpg_gas_pricesbrazil_pharma_medicinesbrazil_purchasing_power_oraclebrazil_tax_anatomyBrazil Macroeconomic and Financial Data AI Platform for AI agents.
Brazilian investments MCP: B3 quotes, fundamentals, portfolio X-ray, theses and news for AI agents.
Banco Central do Brasil (Brazil's central bank) MCP. Keyless public APIs: SGS time series + Olinda…
Brazil Comex Stat MCP — Brazilian foreign trade statistics from MDIC (Ministério do…
Add one secure layer between your agents and this server.
