Eleições 2026 em dados (TSE)

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

With no annotations, the description carries the full disclosure burden. It usefully states the return payload (total votes plus the sq_candidato code), which is the key behavioral fact for a lookup tool, but it says nothing about result caps, default ordering, or how the limite parameter bounds output.

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?

Two short sentences, front-loaded with the verb, resource and year, then the filter list and the return value. Nothing is padded, though the inline filter enumeration and return clause in one sentence make it 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?

For a seven-parameter, zero-annotation, no-output-schema tool, the definition covers purpose and return content adequately. It falls short on the categorical value domains (cargo, situacao, turno) and on the role of limite, which an agent needs in order to build a correct call.

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 0% and no parameter has an enum, so the description must supply value meaning. It names six of the seven parameters as searchable dimensions, which helps, but gives no accepted values for cargo/situacao/turno, no indication of exact vs. partial name matching, and never mentions limite.

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 ("Busca candidatos de 2026") and enumerates the filterable dimensions (nome, UF, cargo, partido, situação, turno). The clause "o código (sq_candidato) para detalhar" implicitly points at the sibling detalhar_candidato, so the agent can distinguish search from detail, though it never names that tool 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?

The follow-up workflow is implied by returning sq_candidato "para detalhar", which suggests using this tool first and detalhar_candidato afterwards. There is no explicit when-to-use/when-not guidance, no statement that all filters are optional, and no mention of what to do when results are empty or too broad.

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

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

With no annotations, the description carries the full burden, and it usefully discloses the shape of the returned data (per-municipality votes by round, declared assets), implying a read-only lookup. It says nothing about behavior for an invalid or missing sq_candidato, or about permissions/rate limits.

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 clause listing the returned content with zero padding. It is efficient, though the fragmentary style leaves the action ('fetch details for') implicit.

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?

There is no output schema, so the description's enumeration of returned fields does real work. However, it stops short of documenting the identifier parameter or when this detail view is the right call over the search sibling.

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 0% for the single parameter 'sq_candidato', and the description does not explain that it is the candidate's unique identifier or its format. The gap in the schema is left uncompensated.

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 the resource (a single candidate's record) and enumerates the payload: public data, votes by municipality per round, and declared assets. That distinguishes it reasonably well from the sibling 'buscar_candidatos', though the retrieval verb is only implied by the noun phrase 'Ficha de um candidato'.

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 explicit guidance on when to use this versus 'buscar_candidatos' or 'explorar'. The singular 'um candidato' weakly implies a detail lookup for an already-known candidate, but the agent must infer that.

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

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

With no annotations supplied, the description carries the whole burden. It correctly frames the tool as a read-only aggregation, giving a useful conceptual model and a hint at the pivot mechanism and filters. However, it says nothing about the shape of the returned table, how the default ordering works, or that limits of 50/500 apply — all of which the agent only discovers from the 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?

Two sentences, zero filler: the first establishes data scope and the pivot mechanics, the second gives usage and an example. Nothing is repeated redundantly from the schema, and the most important framing comes first.

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 7-parameter tool with a nested filtros object, optional column pivoting, and no output schema, an agent still has to guess what the resulting table looks like and how results are ordered or truncated. The description also does not note that both 1st and 2nd round data can be combined. Adequate but with real gaps for a tool of this complexity.

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 86%, so baseline is 3; the description earns a 4 by explaining how linhas, colunas, medida and filtros combine into a pivot layout — the conceptual relationship that a flat enum schema does not convey on its own. It still leaves filtered-value syntax and ordering semantics ("ordem": "nome") to 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?

The description opens with a specific verb and resource ("Tabela dinâmica sobre as eleições de 2026") and then explains the mechanical operation (agrega uma medida por uma dimensão nas linhas e, opcionalmente, outra nas colunas, com filtros), which goes beyond the vague name "explorar". It does not name or distinguish itself from any sibling tool (valores_dimensao, buscar_candidatos), so a 5 is not warranted.

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?

"Use para rankings, comparações e cruzamentos" plus a concrete example (votos por partido em cada UF) gives an agent a clear sense of when to reach for this tool. It stops short of the higher bar because it never excludes scenarios or points to a sibling (e.g. when to use valores_dimensao instead).

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

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

With no annotations at all, the description carries the full behavioral burden and does well: it declares the data provenance (TSE official logs), the privacy boundary (no vote content), per-mode prerequisites, which modes are pure aggregates vs. row-level ('seção por seção'), and the output shape for one mode ('Devolve [minuto, votos, secoes] por minuto'). It stops short of stating return shape for the other five modes, freshness/latency of the data, or that results are capped by `limite`.

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?

It is front-loaded with the resource and data source, then walks the modes in a consistent 'modo=X: ...' pattern, so every clause carries information. The downside is presentation: a single 200+ word block separated only by semicolons, with some repetition of schema-level defaults (17:00, 9:00, PRESIDENTE) that a bulleted mode list would have handled more scannably.

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 16-parameter, six-mode analytical tool with no output schema and no annotations, the description covers what an agent needs to pick a mode and satisfy its prerequisites, plus privacy and provenance context. The remaining gap, return shape for non-`distribuicao` modes, is modest relative to how much of the calling contract is already spelled out.

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 already 88%, so most parameters are self-documenting; the description's added value is linking parameters to modes ('exige uf', 'exige turno e visao', passo/limiar_hora/limiar_tempo confined to modo=explorar) and clarifying the minute-level precision of thresholds. Parameters like `ordem`, `intervalo`, `limite`, and `turno` are left entirely to the schema descriptions, and the enum-level meaning of `medida`/`linhas` values is only sketched conceptually.

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 names the concrete resource and source: polling-station hours for the 2026 election taken from official TSE logs, plus the privacy scope ('não dizem em quem se votou'). It enumerates what each of the six modes returns, so the agent knows exactly what it is getting. It does not, however, explicitly position itself against siblings such as `explorar` or `valores_dimensao`, and the internal mode named 'explorar' overlaps the sibling tool of the same name, which could confuse selection.

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?

Guidance is given per mode, including hard prerequisites ('modo=municipios (exige uf)', 'modo=distribuicao (exige turno e visao)', 'modo=secoes (exige uf; cd_municipio opcional)'), which tells the agent which mode fits which question. It also gives a concrete scenario for `distribuicao` ('votos registrados depois das 17h de Brasília versus votos de urnas que encerraram depois das 17h'). What is missing is any when-not-to-use guidance or explicit pointing to a sibling tool when the question is about candidates rather than urn times.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses that the call is free ('Sem custo'), but it says nothing about return format, units, whether the balance is per-key or shared, or what happens when quota is exhausted — all of which matter for a quota-checking tool.

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?

Two short sentences, front-loaded with the outcome and finished with the cost note. Every clause carries information and nothing is 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 zero-parameter read tool this covers the essentials: what is returned and that it costs nothing. With no annotations and no output schema, though, the description could have said more about the shape or units of the balance returned, leaving a small but real gap.

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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies the key is implicit from the session ('da chave usada'), which is the only 'input' concept here.

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 gives a specific verb ('Mostra') and a specific resource ('o saldo de créditos da chave usada e a cota grátis'), so the agent knows exactly what is returned. It does not name or contrast with any sibling, but the siblings (buscar_candidatos, detalhar_candidato, explorar, valores_dimensao) are unrelated, so confusion is unlikely.

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?

'Sem custo' hints that this is a free, safe call an agent can make at any time, which is useful usage context. However, there is no explicit statement of when to call it (for example, before other paid calls) and no reference to alternatives, so usage is only implied.

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

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

No annotations are supplied, so the description carries the full burden, but 'listar valores possíveis' makes the read-only, non-mutating nature reasonably clear. It does not state whether the returned values are exhaustive, whether they change over time, whether authentication or rate limits apply, or how the result is shaped.

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 the resource stated first and examples second; no filler. Slightly under-specified rather than verbose, which is a content gap more than a structural one.

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 lookup with an enum on dimensao and no output schema, the description covers purpose and a hint at uf's role. It still leaves the agent guessing about return format (list vs. objects with labels) and about which dimensions are valid with or without uf, which is a meaningful gap given the 0% schema coverage.

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 0%, and the description partially compensates: the parenthetical ties 'municipio' results to a UF ('municípios de uma UF'), implicitly explaining that uf scopes the returned values. However, it does not explain the remaining dimension choices or how uf interacts with non-geographic dimensions, so documentation of the two parameters is incomplete.

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 ('Lista os valores possíveis de uma dimensão') and reinforces it with concrete examples (cargos, partidos, municípios de uma UF). It is clearly a lookup/enumeration tool, distinguishable in spirit from siblings like buscar_candidatos or detalhar_candidato, though it never names them 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?

The phrase 'para montar filtros' implies when the tool is useful (to populate filter options before a search), but there is no explicit when-to-use/when-not guidance and no routing to alternatives among the siblings. Usage must be inferred from the stated purpose.

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