Election Index

Resolution sources

resolution_sources

Read-only

Every known source URL for a race, classified (race_results, feed, results_index, emb_home, directory, media). Only race_results and feed can answer a results question; homepages never can. A results page whose HTML shows no count once one is due (figures_in_html false) is not resolvable. Sources a settlement oracle has answered from come first (oracle_reads). For our own copy of the count, see secondary_source in check_question.

Input Schema

TableJSON Schema

Name	Required	Description
`race`	No	Race id, e.g. "president"; optional when the election has one race
`election`	Yes	Election id, e.g. "brazil-general-2026"; list ids with upcoming_elections
`resolvable_only`	No	Only sources that can answer a results question (race_results, feed); default false

Output Schema

TableJSON Schema

Name	Required	Description	Default
`meta`	Yes	What this answer was built from; cite dataset_version
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 17, 2026

addedOutput schema / properties / result / items / properties / figures_in_html

Added value: +{
+  "description": "For a results page: whether its own HTML shows a count (false: figures load by script or the page only links on; null: not read)",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / result / items / properties / oracle_reads

Added value: +{
+  "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+  "type": [
+    "object",
+    "null"
+  ]
+}

First observedSep 27, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: results are ordered with oracle-answered sources first (oracle_reads) and a resolvability rule keyed to figures_in_html. Since output schema exists and annotations cover the safety profile, this is solid added context rather than a full behavioral picture.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause, then progressively narrower constraints follow. It is dense and references output-only concepts (oracle_reads, figures_in_html) without labeling them as such, but every sentence carries decision-relevant information.

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?

With an output schema present, return values need no explanation, and parameters are fully documented. The description supplies the interpretation layer an agent needs (classification meanings, resolvability, ordering) without re-describing fields. Minor gap: it never states whether results are paginated or bounded.

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 the baseline is 3. The description goes further by defining what "resolvable" actually means (only race_results/feed qualify; figures_in_html false disqualifies), which gives the resolvable_only flag semantics beyond the schema's one-line gloss.

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?

"Every known source URL for a race, classified (...)" names a precise resource and enumerates the classification taxonomy, so an agent knows exactly what it gets back. It also distinguishes itself from check_question by redirecting agents who want "our own copy of the count" there. The verb is implicit (a listing), which keeps it just short of 5.

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

Usage Guidelines4/5

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

It gives real selection rules: only race_results and feed can answer a results question, homepages never can, and a page with no count once one is due is not resolvable. It also names check_question for the adjacent need. It stops short of explicit when-to-use/when-not framing but the decision criteria are unusually concrete.

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

All Election Index tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?