Skip to main content
Glama
guilhermelirio

Brasil API MCP

ibge-state-search

Find information about Brazilian states using state codes or abbreviations. Retrieve IBGE data for states through the Brasil API MCP server.

Instructions

Find information about a Brazilian state by its code or abbreviation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesState code or abbreviation (e.g., SP, RJ, 35)

Implementation Reference

  • The handler function for the 'ibge-state-search' tool. It takes a state code or abbreviation, fetches data from BrasilAPI, handles errors, and formats the state information (name, sigla, region, ID) into a text response.
        async ({ code }) => {
          console.error(`Finding state by code/abbreviation: ${code}`);
          
          const result = await getBrasilApiData(`/ibge/uf/v1/${code}`);
          
          if (!result.success) {
            return formatErrorResponse(`Error finding state: ${result.message}`);
          }
          
          // Format the response data
          const state = result.data;
          return {
            content: [{ 
              type: "text" as const, 
              text: `
    State Information:
    Name: ${state.nome}
    Abbreviation: ${state.sigla}
    Region: ${state.regiao.nome}
    ID: ${state.id}
    ` 
            }]
          };
        }
  • Zod schema for the tool input, validating the 'code' parameter as a string with description.
    {
      code: z.string()
        .describe("State code or abbreviation (e.g., SP, RJ, 35)")
    },
  • Registration of the 'ibge-state-search' tool on the MCP server, including name, description, input schema, and handler function.
      // Tool to find state by code or abbreviation
      server.tool(
        "ibge-state-search",
        "Find information about a Brazilian state by its code or abbreviation",
        {
          code: z.string()
            .describe("State code or abbreviation (e.g., SP, RJ, 35)")
        },
        async ({ code }) => {
          console.error(`Finding state by code/abbreviation: ${code}`);
          
          const result = await getBrasilApiData(`/ibge/uf/v1/${code}`);
          
          if (!result.success) {
            return formatErrorResponse(`Error finding state: ${result.message}`);
          }
          
          // Format the response data
          const state = result.data;
          return {
            content: [{ 
              type: "text" as const, 
              text: `
    State Information:
    Name: ${state.nome}
    Abbreviation: ${state.sigla}
    Region: ${state.regiao.nome}
    ID: ${state.id}
    ` 
            }]
          };
        }
      );
  • src/index.ts:29-29 (registration)
    Top-level registration call to registerIbgeTools, which includes the 'ibge-state-search' tool among others.
    registerIbgeTools(server);
  • Helper function used by the handler to fetch data from the BrasilAPI endpoint.
    export async function getBrasilApiData(endpoint: string, params: Record<string, any> = {}) {
      try {
        const url = `${BASE_URL}${endpoint}`;
        console.error(`Making request to: ${url}`);
        
        const response = await axios.get(url, { params });
        return { 
          data: response.data,
          success: true
        };
      } catch (error: any) {
        console.error(`Error in API request: ${error.message}`);
        
        // Handle API errors in a structured format
        if (error.response) {
          return {
            success: false,
            statusCode: error.response.status,
            message: error.response.data?.message || error.message,
            error: error.response.data
          };
        }
        
        return {
          success: false,
          message: error.message,
          error
        };
      }
    }
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the lookup mechanism but doesn't disclose error handling (e.g., invalid codes), response format, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.

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?

The description is a single, efficient sentence with zero waste—it directly states the tool's function and parameter usage. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a lookup tool. It doesn't explain what information is returned (e.g., state name, capital, population), error responses, or any constraints. While the purpose is clear, the lack of behavioral and output details makes it inadequate for full contextual understanding.

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

Parameters3/5

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

Schema description coverage is 100%, with the parameter 'code' well-documented in the schema. The description adds marginal value by clarifying that 'code' can be an abbreviation (e.g., SP, RJ) or numeric code (e.g., 35), but doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Find information') and resource ('about a Brazilian state'), specifying it works by 'code or abbreviation'. It distinguishes itself from siblings like 'ibge-states-list' by focusing on individual state lookup rather than listing all states. However, it doesn't explicitly contrast with 'ibge-municipalities-list' for granularity differences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need state-specific data by code/abbreviation, suggesting an alternative to 'ibge-states-list' for bulk retrieval. However, it lacks explicit guidance on when NOT to use this tool (e.g., for municipality data) or detailed comparisons with siblings like 'ddd-info' for regional info. The context is clear but not comprehensive.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guilhermelirio/brasil-api-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server