Skip to main content
Glama
karnagge

MCP DivulgaCandContas Server

by karnagge

consultar_candidato

Retrieve detailed candidate information from Brazilian elections by providing election year, municipality code, election code, and candidate ID.

Instructions

Consulta informações detalhadas sobre um candidato específico

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
anoYesAno da eleição (ex: 2020)
municipioYesCódigo do município (ex: 35157 para São Paulo)
eleicaoYesCódigo da eleição (ex: 2030402020 para eleições municipais de 2020)
candidatoYesCódigo do candidato

Implementation Reference

  • The main execution logic for the 'consultar_candidato' tool: validates arguments, fetches candidate data from TSE API, and returns formatted details including name, number, party, cargo, situation, and full JSON.
    case "consultar_candidato": {
      const params = ConsultaCandidatoSchema.parse(args);
      const data = await handleApiRequest(() => 
        httpClient.get(`/candidatura/buscar/${params.ano}/${params.municipio}/${params.eleicao}/candidato/${params.candidato}`)
      );
      
      return {
        content: [
          {
            type: "text",
            text: `Informações do candidato:\n\n` +
                  `Nome: ${data.nomeCompleto || data.nomeUrna || 'N/A'}\n` +
                  `Número: ${data.numero || 'N/A'}\n` +
                  `Partido: ${data.partido?.nome || 'N/A'} (${data.partido?.sigla || 'N/A'})\n` +
                  `Cargo: ${data.cargo?.nome || 'N/A'}\n` +
                  `Situação: ${data.descricaoSituacao || 'N/A'}\n\n` +
                  `Detalhes completos:\n${JSON.stringify(data, null, 2)}`
          }
        ]
      };
    }
  • Zod input schema used for validating parameters (ano, municipio, eleicao, candidato) in the consultar_candidato handler.
    const ConsultaCandidatoSchema = z.object({
      ano: z.number().int().min(2000).max(new Date().getFullYear()),
      municipio: z.number().int(),
      eleicao: z.number().int(),
      candidato: z.number().int()
    });
  • src/index.ts:120-147 (registration)
    Tool registration in ListToolsResponse, defining name, description, and JSON input schema for consultar_candidato.
    {
      name: "consultar_candidato",
      description: "Consulta informações detalhadas sobre um candidato específico",
      inputSchema: {
        type: "object",
        properties: {
          ano: {
            type: "number",
            description: "Ano da eleição (ex: 2020)",
            minimum: 2000,
            maximum: new Date().getFullYear()
          },
          municipio: {
            type: "number",
            description: "Código do município (ex: 35157 para São Paulo)"
          },
          eleicao: {
            type: "number", 
            description: "Código da eleição (ex: 2030402020 para eleições municipais de 2020)"
          },
          candidato: {
            type: "number",
            description: "Código do candidato"
          }
        },
        required: ["ano", "municipio", "eleicao", "candidato"]
      }
    },
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'consulta' implies a read-only operation, the description doesn't disclose important behavioral traits such as authentication requirements, rate limits, error conditions, or what format/scope the 'informações detalhadas' includes. For a tool with 4 required parameters and no annotation coverage, this represents a significant gap in behavioral transparency.

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 that gets straight to the point without any unnecessary words. It's appropriately sized for a tool with a clear purpose, and every word contributes to understanding what the tool does. The structure is front-loaded with the core functionality.

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 that this is a read operation with 4 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'informações detalhadas' includes, what format the response will be in, or any behavioral constraints. For a tool that requires multiple specific identifiers to function, the description should provide more context about the nature and scope of the returned information.

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?

The description doesn't add any parameter semantics beyond what's already in the input schema, which has 100% description coverage. The schema already documents all 4 required parameters with descriptions and constraints. Since schema_description_coverage is high (>80%), the baseline score of 3 is appropriate even though the description provides no additional parameter information.

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 tool's purpose as 'Consulta informações detalhadas sobre um candidato específico' (Consult detailed information about a specific candidate), which provides a specific verb ('consulta') and resource ('candidato específico'). However, it doesn't explicitly differentiate from sibling tools like 'listar_candidatos_municipio' which lists candidates rather than retrieving detailed information about one specific candidate.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this tool over sibling tools like 'listar_candidatos_municipio' for listing candidates or other tools for different types of election data. No context about prerequisites or exclusions is provided.

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/karnagge/mcpcand'

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