Skip to main content
Glama

Mestre Prático • Brazil Retail & Commodities MCP

brazil_grocery_basket

Read-onlyIdempotent

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 (Pesquisa de Varejo e Órgãos Reguladores) 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.

Input Schema

NameRequiredDescriptionDefault
ufYesTwo-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pe', 'rs'). Defaults to 'sp'.sp
cidadeNoOptional Brazilian city name or slug to filter local supermarket chains. Defaults to empty string to return statewide summary.
produtoNoOptional food item filter (e.g., 'arroz', 'feijao', 'cafe', 'leite', 'oleo_soja', 'carne', 'pao_frances', 'cesta_basica'). Defaults to 'cesta_basica'.cesta_basica

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / cidade / description
      Previous value: -"Optional Brazilian city name or slug to filter local supermarket chains (e.g., 'rio-de-janeiro', 'cabo-frio', 'recife'). Defaults to empty string to return statewide summary."New value: +"Optional Brazilian city name or slug to filter local supermarket chains. Defaults to empty string to return statewide summary."
    • changedInput schema / properties / uf / description
      Previous value: -"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'pe'). Defaults to 'sp'."New value: +"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pe', 'rs'). Defaults to 'sp'."
    • removedInput schema / properties / uf / enum
      Removed value: -[
      -  "ac",
      -  "al",
      -  "am",
      -  "ap",
      -  "ba",
      -  "ce",
      -  "df",
      -  "es",
      -  "go",
      -  "ma",
      -  "mg",
      -  "ms",
      -  "mt",
      -  "pa",
      -  "pb",
      -  "pe",
      -  "pi",
      -  "pr",
      -  "rj",
      -  "rn",
      -  "ro",
      -  "rr",
      -  "rs",
      -  "sc",
      -  "se",
      -  "sp",
      -  "to"
      -]
  2. Changed3 schema fields changed
    • changedInput schema / properties / cidade / description
      Previous value: -"Optional Brazilian city name or slug to filter local supermarket chains. Defaults to empty string to return statewide summary."New value: +"Optional Brazilian city name or slug to filter local supermarket chains (e.g., 'rio-de-janeiro', 'cabo-frio', 'recife'). Defaults to empty string to return statewide summary."
    • changedInput schema / properties / uf / description
      Previous value: -"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'ba', 'pe', 'rs'). Defaults to 'sp'."New value: +"Two-letter Brazilian state code in lowercase (e.g., 'sp', 'rj', 'mg', 'pe'). Defaults to 'sp'."
    • addedInput schema / properties / uf / enum
      Added value: +[
      +  "ac",
      +  "al",
      +  "am",
      +  "ap",
      +  "ba",
      +  "ce",
      +  "df",
      +  "es",
      +  "go",
      +  "ma",
      +  "mg",
      +  "ms",
      +  "mt",
      +  "pa",
      +  "pb",
      +  "pe",
      +  "pi",
      +  "pr",
      +  "rj",
      +  "rn",
      +  "ro",
      +  "rr",
      +  "rs",
      +  "sc",
      +  "se",
      +  "sp",
      +  "to"
      +]
  3. Changed6 schema fields changed
    • addedInput schema / properties / cidade / default
      Added value: +""
    • changedInput schema / properties / cidade / description
      Previous 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."
    • addedInput schema / properties / produto / default
      Added value: +"cesta_basica"
    • changedInput schema / properties / produto / description
      Previous 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'."
    • addedInput schema / properties / uf / default
      Added value: +"sp"
    • changedInput schema / properties / uf / description
      Previous 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'."
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds genuinely new context — no authentication required, a 60 req/min rate limit, and the underlying source (electronic consumer invoices, DIEESE methodology, 59 regional hubs). It stops short of describing the response shape or price units, which matters since there is no output schema, so it is not a clean 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then structured "When to use" / "When NOT to use" blocks and a trailing operational note. The item parenthetical is long but earns its place by mapping to the produto parameter; no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter, fully documented, fully annotated read-only query, the description covers purpose, alternatives, sourcing, auth and rate limits. The only gap is return-value framing (price units, whether totals and item-level quotes come back together), which the description must carry because no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real value by listing the English item names (rice, beans, coffee, beef, etc.) that map onto the Portuguese produto slugs in the schema, and the "59 regional hubs" framing clarifies what uf/cidade actually scope. It does not exclude invalid combinations of the optional filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ("Queries") plus a precisely scoped resource: real-time audited supermarket prices for Brazil's 13 Basic Food Basket items, with the item list enumerated and the data provenance named. This is clearly distinguishable from region-comparison or index-synthesis siblings 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.

Usage Guidelines5/5

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" routing to two named siblings, brazil_cost_of_living and brazil_purchasing_power_oracle. The exclusion conditions are concrete, not implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.