Neutral, sourced election calendar: polling days, when provisional and final results are due.
Scored across 10 tools
Most tools have distinct specialist roles, but next_election and upcoming_elections could be confused for country-based future-election queries. election_status also overlaps with check_question, when_final, resolution_sources, and poll_blackout, although the detailed descriptions generally clarify when to use each specialist tool.
All names use clear lowercase snake_case with recognizable election-domain terminology. The set mixes verb-led names such as check_question and submit_correction with noun-led and question-style names, so it is not fully patterned but remains predictable and readable.
Ten tools are appropriate for the broad election-data scope. Discovery, status, timing, polling rules, pollster accuracy, provenance, health, and corrections each have a reasonable place without excessive fragmentation.
The surface supports a strong workflow from discovering elections through inspecting stages and results, checking answerability and sources, assessing data trust, and reporting corrections. Minor dead ends remain: full health reports and correction tracking require external URLs, and there is no obvious pollster discovery tool or standalone general results lookup.
Is a question about a given count stage answerable at a given time? Returns verdict ok / too-early / inside-window / too-late, settle_after, and the resolvable sources. Built to stop questions that read the provisional count when they mean the final one.
| Name | Required | Description | Default |
|---|---|---|---|
| race | No | Race id, e.g. "president"; optional when the election has one race | |
| stage | No | Default final-result | |
| ask_at | No | ISO date-time; default now | |
| election | Yes | Election id, e.g. "brazil-general-2026"; list ids with upcoming_elections |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the verdict vocabulary and the notion that the tool also returns settle_after and resolvable sources, which frames the behavior as a guard rather than a data fetch. It does not discuss limits, error modes, or what happens with an unknown race, so it is not exhaustive.
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?
Three tight sentences: the core question first, the return shape second, the motivating rationale last. No filler or repeated name restatement. The verdict list is slightly compressed into a slash-separated string but remains parseable.
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?
With a 100%-documented schema, an output schema, and read-only annotations, the description only needs to convey purpose and the verdict semantics — both are present. The one gap is routing guidance against closely related siblings such as when_final and resolution_sources, which matters given the crowded namespace.
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 100%, so election, race, stage, and ask_at are all documented with examples and defaults in the schema itself. The description only echoes "given count stage" and "given time" without adding format, precedence, or defaulting behavior beyond what the schema states. Baseline 3 is appropriate when the schema carries the semantics.
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 precise, answerable question ("Is a question about a given count stage answerable at a given time?") and states the return contract: verdict ok/too-early/inside-window/too-late plus settle_after and resolvable sources. That is a specific verb+resource, not a restatement of the name. It stops short of naming sibling tools (when_final, election_status) that an agent might confuse it with.
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?
Usage is implied by the closing rationale ("Built to stop questions that read the provisional count when they mean the final one"), which tells the agent this is a pre-flight gate before asking about a count stage. There is no explicit when-to-use/when-not phrasing and no named alternative for cases like "when will the result be final?" where when_final would be the right sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Coverage, stale records, races still lacking a results page, and publisher-gate warnings, as counts with the first 20 of each (full report at /v1/health). Use to judge how far to trust an answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds a genuinely useful behavioral fact: results are truncated to the first 20 of each category, with the full report available at /v1/health. That truncation notice is the kind of operational detail an agent needs and cannot get from the annotations.
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 dense sentence listing the four metric categories, followed by a short usage clause and the truncation caveat. It is front-loaded and wastes no words, though the metric list is slightly comma-heavy and could be easier to scan.
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?
With zero parameters, an output schema present, and annotations declaring read-only local behavior, the description does what is needed: it names the metrics and warns that results are sampled. The only missing piece is guidance on how to act on the counts once retrieved.
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 score applies. The description correctly implies a no-argument call by describing the output rather than any input.
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 enumerates exactly what the tool reports: coverage, stale records, races lacking results pages, and publisher-gate warnings, each as counts plus a first-20 sample. That is specific enough to distinguish it from siblings like check_question or resolution_sources, though it never states the verb explicitly ('returns a health report').
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 to judge how far to trust an answer' gives a clear motivating context for calling it, which is more than nothing. However, it offers no exclusions or comparisons to adjacent tools such as check_question, so the agent must infer when this is preferable to querying an answer directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record of one election: races, polls-close times, every count stage window (exit poll, election night, intermediate count, final result, government) with confidence and citation, the authority, sources, recorded vote counts, whether the record is stale, whether a poll-publication ban (poll_blackout) applies now, and when the exit poll is expected (exit_poll).
| Name | Required | Description | Default |
|---|---|---|---|
| election | Yes | Election id, e.g. "latvia-parliamentary-2026" |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does add real behavioral context beyond that, notably that the record carries its own staleness flag and a blackout-applies-now boolean, which tells the agent results may be outdated or restricted. It says nothing about freshness guarantees, error behavior for unknown ids, or record size.
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?
The lead phrase "Full record of one election" is front-loaded and the remainder is a compact enumeration of contents with no filler sentences. It runs slightly long as a single sentence with a nested parenthetical list, but every clause names a distinct returned artifact.
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 one-parameter read tool with annotations and an output schema, the definition is complete enough to invoke correctly. Most of its length goes toward enumerating return fields that the output schema already carries, which is somewhat redundant, but no calling-critical information is missing.
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?
Only one parameter with 100% schema description coverage, including an example id format ("latvia-parliamentary-2026"), so the schema already fully specifies it. The description adds nothing about the identifier format, valid id discovery, or what happens on an unknown id, leaving it at the baseline for high coverage.
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?
"Full record of one election" states the resource and implicitly the verb (retrieve), and the field list (races, count stages, authority, sources) makes clear what makes this tool different from aggregate siblings like upcoming_elections or next_election. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.
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 when-to-use or when-not-to-use guidance at all. Notably, the description advertises poll_blackout and exit_poll data that overlap with the sibling tools poll_blackout and when_final, yet never says whether an agent should call this tool or those for such questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The next elections in one country, however far ahead: polling day and whether it is declared, still tentative, or only expected within a period, what is elected, the counting authority, and when results are expected. Answers "When is the next election in Austria?" or "When are the US midterms?". National elections by default; level "regional" answers "When are the next state elections in Germany?". Covers 390 elections in 100 countries, 2021–2030, including 23 of the 27 EU member states, the 2026 US midterms in all 50 states and the certified 2024 US presidential result, with vote counts, in all 50 states and DC.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many upcoming elections to return, soonest first; default 3 | |
| level | No | national: the country votes; regional: a state, region or autonomous community elects its own parliament or head (German Länder, Spanish autonomous communities, Italian regions). Default national; the answer also counts upcoming regional elections | |
| country | Yes | Country name or ISO 3166-1 alpha-2 code, e.g. "Austria" or "AT", "United States" or "US" |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
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 genuine behavioral context beyond that — the temporal reach ("however far ahead"), the distinction between declared, tentative and expected-within-a-period results, and the dataset boundaries (390 elections, 100 countries, 2021–2030). It does not address ordering beyond a default, pagination limits, or behavior when no upcoming election exists.
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?
The first two sentences are front-loaded and functional, but the closing inventory ("390 elections in 100 countries... 23 of the 27 EU member states... certified 2024 US presidential result, with vote counts") reads as promotional coverage statistics rather than guidance an agent needs to invoke the tool. It inflates length without changing call behavior.
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?
With an output schema present, return values need not be explained, and the read-only annotations cover the safety profile. The description supplies scope, defaults and examples, leaving only the relationship to sibling tools and the empty-result case unaddressed — modest gaps for a three-parameter lookup.
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 100%, so the baseline is 3. The description does add some meaning — that results are national by default, that "however far ahead" applies, and a concrete illustration of level=regional (German state elections) — but these largely echo the enum descriptions already in the schema rather than adding new semantics such as how "all" interacts with national counting.
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 states a specific resource and scope: the next elections in one country, with polling day, declared/tentative status, what is elected, counting authority and expected results. An agent can tell what it returns. However, it never mentions or distinguishes itself from the sibling upcoming_elections or election_status, which appear to overlap heavily with this tool.
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?
Usage is made concrete through example questions ("When is the next election in Austria?", "When are the US midterms?") and an explicit default (national level) with the regional case explained. It gives clear context for when to reach for it, but provides no exclusions or pointers to the overlapping siblings, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a country bans publishing opinion polls before a vote, checked now: verdict ban / no-ban / exit-polls-only / unverified, when a ban starts and ends (polls close), whether it is in force, the law and article, and the official text it was read in. Answers "Can I publish a poll in Spain this week?" or "When does the poll blackout end in Serbia?". Give an election id, or a country for its next vote. "unverified" means we hold no verified rule: it is not a finding that polls are allowed. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country name or ISO 3166-1 alpha-2 code, e.g. "Austria" or "AT", "United States" or "US"; answers for its next election | |
| election | No | Election id, e.g. "spain-general-2026" |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it read-only; the description goes well beyond by defining the 'unverified' verdict as absence of a verified rule rather than a permission finding — a critical misuse guard — and by adding the 'Not legal advice' disclaimer for a legally consequential answer. It also discloses the evidentiary basis (law and article, official text read) behind each verdict.
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?
The verdict list and the 'unverified' caveat are front-loaded, and every clause carries information. The single sentence enumerating returned fields runs long and could be tightened, but nothing is filler.
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?
An output schema exists, so return-value explanation is optional, yet the description still summarizes what comes back. Combined with the verdict taxonomy, the negative-case semantics, and the legal caveat, an agent has everything needed to call it and to frame the answer correctly.
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 100%, so the baseline is 3, but the description adds the either/or relationship between the two optional parameters ('Give an election id, or a country for its next vote') and the consequence of choosing country (it answers for the next election), which the schema alone does not state.
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 resource (pre-election poll publication rules) and enumerates the exact verdict vocabulary (blocked/enforced/partial/none), plus the returned fields (window dates, in-force status, statute citation, official source text). An agent can distinguish this from election_status or next_election purely from the text.
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?
It supplies two concrete usage examples ('Can I publish a poll in Spain this week?', 'When does the poll blackout end in Serbia?') and states the two input modes: an election id, or a country resolved to its next vote. It does not explicitly name sibling tools or say when NOT to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A pollster's final published poll before each election we hold a certified result for, set against that result: share per party or candidate, error in points, mean absolute error, and the error on the winner's margin. Figures come from the pollster's own release or a registry, never an aggregator. Measured facts, not grades: nothing is ranked. Answers "How accurate was Novus in Sweden 2026?". Give a pollster id or name.
| Name | Required | Description | Default |
|---|---|---|---|
| pollster | Yes | Pollster id or name, e.g. "novus" or "Verian" |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes | The pollster and its final polls, each with against_result (rows, mean_abs_error, margin_error, margin_towards: the count’s name for the contestant the poll leaned to, margin_towards_label: as readers know it, leader_same_as_result) or not_comparable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint the description adds real behavioral substance: the data comes from the pollster's own release or a registry and never an aggregator, and results are measured facts with no ranking or grading. It does not say what happens when a pollster has no certified-result history or the name is ambiguous, which is the remaining gap.
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?
Dense but front-loaded: scope, then metrics, then provenance, then the disambiguating 'measured facts, not grades', then the example question. The metric list ('error in points, mean absolute error, and the error on the winner's margin') is slightly compressed, but every clause carries information.
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?
With an output schema present, the description needn't enumerate return fields, and it still previews them usefully alongside provenance guarantees. The only incompleteness is failure/edge behavior for unknown pollsters or pollsters lacking certified results.
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 100% with a single required 'pollster' field already documented with examples ("novus", "Verian"). The description's 'Give a pollster id or name' merely echoes that id-or-name flexibility, adding no new semantics such as matching behavior or ambiguity handling.
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 exact resource (a pollster's final published poll before each election with a certified result) and the exact comparison being produced (poll vs. result, with per-party share, error, MAE, winner-margin error). Nothing here overlaps with siblings like election_status or next_election, so an agent can route to it confidently.
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 sample question 'How accurate was Novus in Sweden 2026?' plus 'Give a pollster id or name' gives clear usage context and an input cue. It stops short of explicit when-not guidance or naming an alternative sibling (e.g., where to go for pollster-less poll data), so it sits just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavior beyond that — result ordering ("Sources a settlement oracle has answered from come first (oracle_reads)"), the meaning of the classification buckets, and a concrete non-resolvability condition. These are exactly the traits an agent needs to interpret the returned list rather than just knowing the call is a safe read.
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?
Four short sentences, each carrying distinct information, with the core definition front-loaded and the sibling cross-reference last. The density of internal jargon (emb_home, figures_in_html, oracle_reads) makes it slightly harder to parse on first read, but nothing is redundant.
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 three-parameter read tool with an output schema already present, the description covers everything an agent needs: what is returned, how it is classified, what ordering to expect, and how to judge resolvability. Return-value structure is correctly left to the output schema.
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 100%, so the baseline is 3, but the description earns more by explaining the underlying concept that resolvable_only filters on: what "resolvable" means and why a results page can fail it. It also contextualizes race/election ids through the sibling upcoming_elections pointer, though it does not restate the race-optionality rule itself.
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 resource and scope — "Every known source URL for a race" — and immediately gives the classification taxonomy (race_results, feed, results_index, emb_home, directory, media). It also explicitly routes the agent elsewhere for a related but different need ("For our own copy of the count, see secondary_source in check_question"), so it is distinguishable from siblings like check_question without opening any schema.
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?
It states precisely which sources can answer a results question ("Only race_results and feed"), rules out a whole class ("homepages never can"), and gives a negative resolvability rule tied to figures_in_html. It also names the alternative tool for the adjacent task, giving both when-to-use and when-to-look-elsewhere guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a mistake or a missing election, with a URL that proves it (ideally the official authority page). The report is public and is checked like any other claim; it never changes the data by itself. Returns the report id; follow it at https://electionindex.org/corrections.
| Name | Required | Description | Default |
|---|---|---|---|
| race | No | Race id within that election, if the report is about one race | |
| claim | Yes | What is wrong and what is right, 10 to 2000 characters | |
| election | No | Election id, if the report is about a listed election | |
| evidence | Yes | http(s) URL of the page that proves it |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: the report is public, is reviewed 'like any other claim', and does not itself change the data — which reconciles the readOnlyHint=false with the user's likely fear of mutating the dataset. It also discloses the return value (report id) and where to follow it, which annotations never cover.
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?
Three tight sentences, front-loaded with the action, followed by the constraint and the outcome. No filler and no repetition of the schema.
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 four-parameter submission tool with full schema coverage and an output schema, nothing an agent needs is missing: causality (does not alter data), visibility (public review), and follow-up URL are all stated.
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 100%, so the baseline would be 3; the description earns an extra point by clarifying the nature of the 'evidence' parameter (a proving URL, ideally the official authority page) in a way the raw 'http(s) URL of the page that proves it' does not fully convey. It says nothing extra about the optional race/election scoping parameters, which the schema already handles.
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 ('Report a mistake or a missing election') plus the required artifact ('a URL that proves it'). This is immediately distinguishable from all listed siblings, which are read-style query tools (election_status, pollster, dataset_health, etc.).
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?
Gives clear context for when to use it: reporting an error or an absent election, including the guidance that evidence should ideally be the official authority page. It does not name an alternative or explicitly say when not to use it (e.g., that questions about how data is collected belong to check_question), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List elections by date range and/or country, soonest first, with each race's expected count stage right now. Answers "Which elections are in Europe this autumn?", "Which elections are this month?" or "What elections does Germany have coming up?". Without dates it starts today; with a country and no end date it covers every future election of that country, otherwise the next 365 days. Covers 390 elections in 100 countries, 2021–2030, including 23 of the 27 EU member states, the 2026 US midterms in all 50 states and the certified 2024 US presidential result, with vote counts, in all 50 states and DC.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date YYYY-MM-DD; default +365 days, or no end when a country is given | |
| from | No | Start date YYYY-MM-DD; default today | |
| level | No | national: the country votes; regional: a state, region or autonomous community elects its own parliament or head (German Länder, Spanish autonomous communities, Italian regions). Default all | |
| limit | No | Most elections to return, soonest first; default 25, max 200. Narrow with from/to or country for more. | |
| country | No | Country name or ISO 3166-1 alpha-2 code, e.g. "Austria" or "AT", "United States" or "US" | |
| include_discovered | No | Also list elections found on Wikidata but not yet verified by Global Election Index |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scoping behavior (default date windows, ordering) and hints at verification status through include_discovered. Remaining gaps are minor: pagination behavior and the vague "expected count stage right now" phrase that is never explained.
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?
Front-loaded with the verb, scope, and ordering, then examples, then defaults, which is good structure with no wasted sentences. The closing coverage sentence (390 elections, 23 of 27 EU states, US midterms and certified 2024 result) reads more like marketing than invocation guidance, so it is slightly overlong.
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?
An output schema exists and parameter coverage is complete, so the description does not need to explain return values. It covers defaults, scope, and dataset breadth adequately, but leaves the include_discovered trust distinction and the "expected count stage" concept underspecified.
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 100%, so baselines at 3. The description restates the from/to defaults already documented in the schema and repeats the "narrow with from/to or country" advice that also appears in the limit description, adding little new meaning. It never explains include_discovered's trust implications or the level enum beyond what the schema already says.
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?
Opens with a specific verb and resource plus ordering ("List elections by date range and/or country, soonest first"), and the example questions pin down that this returns sets of races rather than one election. It does not name a sibling such as next_election or election_status to draw the boundary explicitly, so it stops short of the top band.
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?
Gives concrete when-to-use cues via three example questions and spells out the default windows (today when no dates, all future elections for a country with no end date, otherwise 365 days). There is no explicit when-not guidance or pointer to the sibling tools an agent should prefer for single-race or status queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When will a race's final (certified) result exist? Returns the expected window, its confidence (announced / precedent / estimate) and basis, how many days the final took last time, and the final count itself once we hold it. Use this before asking or settling any "final result" question.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version |
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses the epistemic character of the answer — the window may be based on an announcement, precedent, or an estimate — and warns that the final count is only present "once we hold it." That tells the agent how much to trust and how to handle an absent count, which is real value not present in the annotations.
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?
Three sentences, front-loaded with the core question before the return-value detail and the usage directive. The middle sentence is dense but its list maps cleanly to distinct outputs. No filler wording; the only mild redundancy is re-listing returns when an output schema exists.
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?
The tool is low-complexity (one required string parameter) and an output schema exists, so the description need not spell out the response shape — yet it usefully characterizes the confidence tiers. It stops short of saying what happens when no estimate is available at all or how far out the window can be, which an agent preparing a fallback would want.
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 100%, so both parameters (election, race) are already documented with examples and the optionality rule for race. The description adds no syntax, format, or disambiguation guidance for these parameters. Baseline 3 is correct when the schema carries the full parameter burden.
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 question the tool answers — when a race's certified final result will exist — and then enumerates what comes back (expected window, confidence tier, precedent duration, final count). That is a clear verb+resource statement an agent can act on. It does not name a sibling such as election_status, so the boundary with adjacent tools is implied rather than stated.
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 this before asking or settling any 'final result' question" gives a concrete trigger condition, which is more than most definitions offer. However, it provides no exclusions — it never says when to prefer election_status or resolution_sources instead, leaving the agent to infer the split between timing questions and status questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_question1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}dataset_health1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}election_status1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}next_election1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}poll_blackout1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}pollster1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}resolution_sources1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}submit_correction1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}upcoming_elections1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}when_final1 field changedOutput schema / properties / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}check_question1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}dataset_health1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}election_status1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}next_election1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}poll_blackout1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}pollster1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}resolution_sources1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}submit_correction1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}upcoming_elections1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}when_final1 field changedOutput schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}election_status1 field changedOutput schema / properties / result / properties / races / items / properties / results / items / properties / rows / items / properties / ballot_nameAdded value: +{
+ "description": "Name on the ballot, as the authority's file writes it",
+ "type": [
+ "string",
+ "null"
+ ]
+}next_election1 field changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / ballot_nameAdded value: +{
+ "description": "Name on the ballot, as the authority's file writes it",
+ "type": [
+ "string",
+ "null"
+ ]
+}upcoming_elections1 field changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / ballot_nameAdded value: +{
+ "description": "Name on the ballot, as the authority's file writes it",
+ "type": [
+ "string",
+ "null"
+ ]
+}when_final1 field changedOutput schema / properties / result / properties / final_result / properties / rows / items / properties / ballot_nameAdded value: +{
+ "description": "Name on the ballot, as the authority's file writes it",
+ "type": [
+ "string",
+ "null"
+ ]
+}pollster1 field changedOutput schema / properties / result / descriptionPrevious value: -"The pollster and its final polls, each with against_result (rows, mean_abs_error, margin_error and margin_towards, leader_same_as_result) or not_comparable"New value: +"The pollster and its final polls, each with against_result (rows, mean_abs_error, margin_error, margin_towards: the count’s name for the contestant the poll leaned to, margin_towards_label: as readers know it, leader_same_as_result) or not_comparable"pollsterpoll_blackoutelection_status1 field changedOutput schema / properties / result / properties / exit_pollAdded value: +{
+ "description": "When is the exit poll? An exit poll is a survey of voters leaving polling stations, never an official result",
+ "properties": {
+ "at": {
+ "description": "The one time to show: when it was published, else when it is due (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ban_ends": {
+ "description": "While a verified ban is in force: at (UTC, polls close), local, citation, scope (publication: all polls; exit-polls: exit-poll results only)",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "basis": {
+ "description": "What the expectation, or the finding that none is published, rests on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "by": {
+ "description": "Latest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "checked_at": {
+ "description": "For none: when that was checked (YYYY-MM-DD)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "confidence": {
+ "description": "announced, precedent or estimate",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "from": {
+ "description": "Earliest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_at": {
+ "description": "When it was published, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_source": {
+ "description": "Page that shows the publication, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "official_result": {
+ "description": "Always false",
+ "type": "boolean"
+ },
+ "publisher": {
+ "description": "Who publishes it, e.g. a broadcaster and its pollster",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "race": {
+ "description": "The race the answer is recorded on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "Where it is published",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "expected (due), past (due time has passed, publication not observed), published (observed), none (checked: no exit poll is published), or unknown (not yet recorded)",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}next_election1 field changedOutput schema / properties / result / properties / elections / items / properties / exit_pollAdded value: +{
+ "description": "When is the exit poll? An exit poll is a survey of voters leaving polling stations, never an official result",
+ "properties": {
+ "at": {
+ "description": "The one time to show: when it was published, else when it is due (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ban_ends": {
+ "description": "While a verified ban is in force: at (UTC, polls close), local, citation, scope (publication: all polls; exit-polls: exit-poll results only)",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "basis": {
+ "description": "What the expectation, or the finding that none is published, rests on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "by": {
+ "description": "Latest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "checked_at": {
+ "description": "For none: when that was checked (YYYY-MM-DD)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "confidence": {
+ "description": "announced, precedent or estimate",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "from": {
+ "description": "Earliest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_at": {
+ "description": "When it was published, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_source": {
+ "description": "Page that shows the publication, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "official_result": {
+ "description": "Always false",
+ "type": "boolean"
+ },
+ "publisher": {
+ "description": "Who publishes it, e.g. a broadcaster and its pollster",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "race": {
+ "description": "The race the answer is recorded on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "Where it is published",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "expected (due), past (due time has passed, publication not observed), published (observed), none (checked: no exit poll is published), or unknown (not yet recorded)",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}upcoming_elections1 field changedOutput schema / properties / result / properties / elections / items / properties / exit_pollAdded value: +{
+ "description": "When is the exit poll? An exit poll is a survey of voters leaving polling stations, never an official result",
+ "properties": {
+ "at": {
+ "description": "The one time to show: when it was published, else when it is due (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ban_ends": {
+ "description": "While a verified ban is in force: at (UTC, polls close), local, citation, scope (publication: all polls; exit-polls: exit-poll results only)",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "basis": {
+ "description": "What the expectation, or the finding that none is published, rests on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "by": {
+ "description": "Latest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "checked_at": {
+ "description": "For none: when that was checked (YYYY-MM-DD)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "confidence": {
+ "description": "announced, precedent or estimate",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "from": {
+ "description": "Earliest expected publication (UTC ISO)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_at": {
+ "description": "When it was published, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "observed_source": {
+ "description": "Page that shows the publication, once observed",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "official_result": {
+ "description": "Always false",
+ "type": "boolean"
+ },
+ "publisher": {
+ "description": "Who publishes it, e.g. a broadcaster and its pollster",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "race": {
+ "description": "The race the answer is recorded on",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "Where it is published",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "expected (due), past (due time has passed, publication not observed), published (observed), none (checked: no exit poll is published), or unknown (not yet recorded)",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}election_status1 field changedOutput schema / properties / result / properties / poll_blackoutAdded value: +{
+ "description": "Whether opinion polls for this election should be shown only behind a warning right now, checked at request time. reason \"ban\": a poll-publication ban applies under the cited law. reason \"unverified\": we hold no verified rule for this country, so we cannot say publishing is allowed; it is not a finding that polls are banned. Show polls behind a warning (mode warn) or not at all (mode withhold)",
+ "properties": {
+ "active": {
+ "description": "Show polls only behind a warning now (see reason)",
+ "type": "boolean"
+ },
+ "citation": {
+ "description": "The law and provision behind an active or upcoming ban",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "date_tentative": {
+ "description": "Polling day is not declared yet, so these times may move",
+ "type": "boolean"
+ },
+ "ends_at": {
+ "description": "When the ban or warning ends: the last polls close (UTC ISO)",
+ "type": "string"
+ },
+ "ends_at_local": {
+ "description": "The same moment in local time, with offset",
+ "type": "string"
+ },
+ "mode": {
+ "description": "warn: polls may be shown behind a warning; withhold: do not show them",
+ "type": "string"
+ },
+ "reason": {
+ "description": "ban (a verified ban applies), unverified (no verified rule; warning until polls close), or null",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rule": {
+ "description": "The rule as recorded",
+ "properties": {
+ "citation": {
+ "description": "The provision",
+ "type": "string"
+ },
+ "id": {
+ "description": "Rule id",
+ "type": "string"
+ },
+ "law": {
+ "description": "The law, by its own title",
+ "type": "string"
+ },
+ "legal": {
+ "description": "Quote, English gloss, what it covers, whether it covers online publication, exemptions, penalty, enforcer",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "note": {
+ "description": "Reading notes",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "description": "What is banned: publication, exit-polls",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Official text the rule was read in",
+ "type": "string"
+ },
+ "verified_at": {
+ "description": "When the rule was last read against the source (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "starts_at": {
+ "description": "When the ban starts (UTC ISO); null if the law sets none or no rule is known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timezone": {
+ "description": "IANA time zone of ends_at_local",
+ "type": "string"
+ },
+ "verified": {
+ "description": "We hold a rule for this country read against the law",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}next_election1 field changedOutput schema / properties / result / properties / elections / items / properties / poll_blackoutAdded value: +{
+ "description": "Whether opinion polls for this election should be shown only behind a warning right now, checked at request time. reason \"ban\": a poll-publication ban applies under the cited law. reason \"unverified\": we hold no verified rule for this country, so we cannot say publishing is allowed; it is not a finding that polls are banned. Show polls behind a warning (mode warn) or not at all (mode withhold)",
+ "properties": {
+ "active": {
+ "description": "Show polls only behind a warning now (see reason)",
+ "type": "boolean"
+ },
+ "citation": {
+ "description": "The law and provision behind an active or upcoming ban",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "date_tentative": {
+ "description": "Polling day is not declared yet, so these times may move",
+ "type": "boolean"
+ },
+ "ends_at": {
+ "description": "When the ban or warning ends: the last polls close (UTC ISO)",
+ "type": "string"
+ },
+ "ends_at_local": {
+ "description": "The same moment in local time, with offset",
+ "type": "string"
+ },
+ "mode": {
+ "description": "warn: polls may be shown behind a warning; withhold: do not show them",
+ "type": "string"
+ },
+ "reason": {
+ "description": "ban (a verified ban applies), unverified (no verified rule; warning until polls close), or null",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rule": {
+ "description": "The rule as recorded",
+ "properties": {
+ "citation": {
+ "description": "The provision",
+ "type": "string"
+ },
+ "id": {
+ "description": "Rule id",
+ "type": "string"
+ },
+ "law": {
+ "description": "The law, by its own title",
+ "type": "string"
+ },
+ "legal": {
+ "description": "Quote, English gloss, what it covers, whether it covers online publication, exemptions, penalty, enforcer",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "note": {
+ "description": "Reading notes",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "description": "What is banned: publication, exit-polls",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Official text the rule was read in",
+ "type": "string"
+ },
+ "verified_at": {
+ "description": "When the rule was last read against the source (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "starts_at": {
+ "description": "When the ban starts (UTC ISO); null if the law sets none or no rule is known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timezone": {
+ "description": "IANA time zone of ends_at_local",
+ "type": "string"
+ },
+ "verified": {
+ "description": "We hold a rule for this country read against the law",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}upcoming_elections1 field changedOutput schema / properties / result / properties / elections / items / properties / poll_blackoutAdded value: +{
+ "description": "Whether opinion polls for this election should be shown only behind a warning right now, checked at request time. reason \"ban\": a poll-publication ban applies under the cited law. reason \"unverified\": we hold no verified rule for this country, so we cannot say publishing is allowed; it is not a finding that polls are banned. Show polls behind a warning (mode warn) or not at all (mode withhold)",
+ "properties": {
+ "active": {
+ "description": "Show polls only behind a warning now (see reason)",
+ "type": "boolean"
+ },
+ "citation": {
+ "description": "The law and provision behind an active or upcoming ban",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "date_tentative": {
+ "description": "Polling day is not declared yet, so these times may move",
+ "type": "boolean"
+ },
+ "ends_at": {
+ "description": "When the ban or warning ends: the last polls close (UTC ISO)",
+ "type": "string"
+ },
+ "ends_at_local": {
+ "description": "The same moment in local time, with offset",
+ "type": "string"
+ },
+ "mode": {
+ "description": "warn: polls may be shown behind a warning; withhold: do not show them",
+ "type": "string"
+ },
+ "reason": {
+ "description": "ban (a verified ban applies), unverified (no verified rule; warning until polls close), or null",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rule": {
+ "description": "The rule as recorded",
+ "properties": {
+ "citation": {
+ "description": "The provision",
+ "type": "string"
+ },
+ "id": {
+ "description": "Rule id",
+ "type": "string"
+ },
+ "law": {
+ "description": "The law, by its own title",
+ "type": "string"
+ },
+ "legal": {
+ "description": "Quote, English gloss, what it covers, whether it covers online publication, exemptions, penalty, enforcer",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "note": {
+ "description": "Reading notes",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "description": "What is banned: publication, exit-polls",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Official text the rule was read in",
+ "type": "string"
+ },
+ "verified_at": {
+ "description": "When the rule was last read against the source (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "starts_at": {
+ "description": "When the ban starts (UTC ISO); null if the law sets none or no rule is known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timezone": {
+ "description": "IANA time zone of ends_at_local",
+ "type": "string"
+ },
+ "verified": {
+ "description": "We hold a rule for this country read against the law",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}UK GCSE and A-level exam dates, results days, entry deadlines and spec changes.
US race matchups — one call per federal race: who holds the seat, who is running, which of them…
Public holidays, business days and long weekends for about 250 countries, in each local time zone.
Free read-only Israeli election, polling and dated CBS population data in four languages.
Add one secure layer between your agents and this server.