Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Brazil Retail & Fuel Price Intelligence MCP Server compare gasoline and ethanol prices in São Paulo and Rio de Janeiro"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official sovereign Model Context Protocol (MCP) server providing real-time audited fuel prices (ANP) and grocery basket indices (SEFAZ NFC-e) across all 27 Brazilian states and 417+ cities.
Built and maintained by Holding Arthur Luis Vieira dos Santos (Mestre Prático & NutriPreço).
Endpoint URL: https://mestrepratico.com.br/mcp/v1
Interactive Developer Portal: https://mestrepratico.com.br/developers
Consumer Portals: Mestre Prático | NutriPreço
Related MCP server: mcp-brasil
Add this directly to your claude_desktop_config.json or MCP client settings:
{
"mcpServers": {
"mestrepratico": {
"type": "http",
"url": "https://mestrepratico.com.br/mcp/v1"
}
}
}brazil_fuel_prices
Queries official audited fuel prices (Regular Gasoline, Additive Gasoline, Ethanol, Diesel S10, CNG) from Brazil's National Petroleum Agency (ANP) across 4,750+ gas stations in all 27 states (sp, rj, mg, ba, pr, rs, df, etc.).
brazil_grocery_basket
Queries and compares audited prices of Brazil's basic food basket (rice, beans, coffee, oil, milk, sugar, beef) sourced from electronic consumer invoices (NFC-e SEFAZ).
cost_of_living_brazil
Returns consolidated regional cost-of-living metrics, purchasing power parity, and live BRL/USD comparisons for expats, digital nomads, and economic analysts.
MIT License — Holding Arthur Luis Vieira dos Santos.
Queries real-time audited fuel prices (Gasoline, Ethanol, Diesel S10, CNG) from Brazil ANP across 4,750+ stations in all 27 states.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Brazilian state code (e.g., 'sp', 'rj', 'mg', 'ba', 'pr', 'rs', 'df') | |
| cidade | No | City name or slug (e.g., 'sao-paulo', 'cabo-frio') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add useful provenance context (ANP, audited, real-time, coverage figures), and 'Queries' implies a read-only operation, but it says nothing about rate limits, auth requirements, pagination, or return shape.
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?
A single dense sentence with zero filler; the core capability and data scope are front-loaded. Nothing in it is redundant or padded.
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 two-parameter read query with full schema coverage and no output schema, the description covers what an agent needs to know before calling it: what data, from where, and how fresh. Only return-format details are absent, and there is no output schema demanding them.
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 documented with examples in the schema. The description adds no parameter-level meaning beyond that, making the baseline 3 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?
States a specific verb (Queries) and resource (real-time audited fuel prices) plus the data source (ANP) and scope (4,750+ stations, 27 states). An agent can distinguish this from brazil_grocery_basket and cost_of_living_brazil, though the description never explicitly contrasts itself with those siblings.
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?
Usage is only implied: the description makes clear you call this when you need Brazilian fuel price data, but it names no alternatives, no when-not-to-use conditions, and no prerequisites. No sibling routing guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries and compares audited prices of Brazil's basic food basket sourced from electronic consumer invoices (NFC-e SEFAZ).
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Brazilian state code (e.g., 'sp', 'rj') | |
| cidade | No | City name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses provenance ('audited', 'electronic consumer invoices (NFC-e SEFAZ)'), which tells the agent the data is official and traceable, but says nothing about freshness, coverage, rate limits, or return shape.
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?
A single front-loaded sentence with no filler; the resource and its data source are packed efficiently with zero redundancy against title or 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 two-parameter read-only query with full schema coverage, the description covers what the data is but omits how 'compares' works (across states, cities, or time), the required geographic granularity, and any indication of return shape in the absence of an output schema. Adequate but with visible gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema (uf as Brazilian state code, cidade as city name). The description adds no syntax, format, or interaction detail beyond what the schema provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (queries and compares) and a specific resource (Brazil's basic food basket prices), plus its provenance (NFC-e SEFAZ audited invoices). This clearly separates it from brazil_fuel_prices and cost_of_living_brazil by data domain, 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?
There is no when-to-use guidance, no mention of alternatives for price/cost queries, and no prerequisites. The only hint of usage is the word 'compares,' which implies cross-location comparison but leaves the agent to infer the trigger conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns consolidated regional cost-of-living index and purchasing power parity (BRL/USD) in Brazil.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | No | State code | |
| comparar_com_dolar | No | Convert to USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Returns' implies a read-only operation and it discloses the output content (index plus PPP rate and currency pair), which is useful. However, it says nothing about data source, update cadence, geographic granularity when uf is omitted, or whether the tool works with zero parameters.
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?
A single front-loaded sentence with no filler. Each element (index, PPP, currency pair, geography) earns 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?
For a simple read tool with no output schema and fully documented optional parameters, the description covers the core return content adequately. Minor gaps remain around scope behavior when uf is omitted and the empty-parameter 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%, so both parameters are documented in the schema itself. The mention of BRL/USD loosely maps to comparar_com_dolar, but no format, default, or behavior for an empty uf is added 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 (Returns) and resource (regional cost-of-living index and purchasing power parity in BRL/USD) scoped to Brazil. It is clearly distinguishable from siblings like brazil_fuel_prices and brazil_grocery_basket by subject matter, though it never explicitly contrasts with them.
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 offers no when-to-use guidance, no prerequisites, and never references the sibling tools that cover adjacent Brazilian economic data. The agent must infer applicability purely from the resource name.
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.
v1.0.0brazil_fuel_pricesbrazil_grocery_basketcost_of_living_brazilScored across 3 tools
Each tool targets a distinct dataset: fuel prices, grocery basket, and cost-of-living index. There is mild conceptual overlap between brazil_grocery_basket and cost_of_living_brazil (both touch on consumer costs), but the descriptions make the boundary reasonably clear.
Two tools follow a 'brazil_<noun>' prefix pattern (brazil_fuel_prices, brazil_grocery_basket), but cost_of_living_brazil puts the country at the end instead. Readable overall, but the pattern breaks in a small set where consistency is easy to achieve.
Three tools is thin for a data-intelligence server covering multiple datasets. Each tool earns its place, but the surface feels like a minimal MVP rather than a well-rounded set.
All three tools are read-only queries with no apparent supporting operations such as listing covered states, stations, time ranges, or comparing regions across datasets. The core query surface exists, but agents will hit dead ends for discovery and drill-down tasks.
Brazilian public data API for AI agents. BCB, IBGE, CVM, B3, compliance. x402 payments on Base.
Brazil CNPJ, CEP, Selic/IPCA/PTAX, holidays, banks/ISPB for agents. Pay per call in USDC (x402).
Brazilian company data, CNPJ/CPF validation and KYB risk score. Pay per call via x402 (USDC).
Discover, resolve, and query official Brazilian economic data with semantic search and provenance.