Neutral, sourced election calendar: polling days, when provisional and final results are due.
Scored across 8 tools
Most tools have distinct roles, but next_election and upcoming_elections substantially overlap—both answer 'what elections are coming up' for a country, and their descriptions even duplicate the same coverage blurb. check_question and when_final also share timing/resolvability concerns, though the descriptions give enough nuance to separate them.
Names mix noun phrases (election_status, resolution_sources, dataset_health), verb_noun commands (check_question, submit_correction), and an interrogative-style name (when_final). All are snake_case and readable, but there is no single predictable pattern.
Eight tools is well-scoped for an election-data service, with seven read/query tools plus one write (submit_correction). No obvious filler or redundancy that would bloat the surface.
The surface covers status, upcoming/next listings, source resolution, final-result timing, answerability checks, dataset trust, and corrections—a solid read-oriented lifecycle. The main gap is a direct search/lookup-by-name or race-id tool to locate a specific election before drilling in.
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 the verdict taxonomy and mentions settle_after and resolvable sources, but since an output schema exists this is largely return-value information rather than deeper behavioral context (no auth, rate-limit, or ambiguity-handling notes).
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 short sentences, front-loaded with the core question and tightly followed by the return vocabulary. The third sentence is motivational rather than operational but still earns its place by framing the tool's intent.
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 needn't be spelled out, and the required-parameter surface is simple (one required election id). The description covers purpose and stage semantics adequately; only explicit alternative-tool routing 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?
Schema description coverage is 100% and each parameter is documented with examples and defaults in the schema itself. The description gestures at 'given count stage' and 'given time' but adds no semantics beyond what the schema already provides, so the baseline of 3 applies.
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 opening question states a concrete verb and resource ('Is a question about a given count stage answerable at a given time?') and enumerates the possible verdicts, so an agent knows exactly what comes back. It doesn't name a sibling to contrast with (e.g. when_final or resolution_sources), so differentiation is inferred rather than explicit.
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?
'Built to stop questions that read the provisional count when they mean the final one' gives a clear motivating scenario, which implies when to reach for this tool. However, it never states when NOT to use it or names an alternative tool for adjacent needs, leaving the agent to infer usage from the sibling list.
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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are counts truncated to the first 20 of each category, with the full report available at /v1/health, which tells the agent the output is deliberately partial.
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, front-loaded with the payload contents and followed immediately by the use case. The category enumeration is long but each item describes distinct returned data, so it earns its space.
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 in prose, and the description still adds the truncation rule and the /v1/health escape hatch. For a no-input diagnostic tool this covers everything an agent needs to call it 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?
The tool takes no parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for a zero-parameter tool applies.
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 – so the resource and content are unmistakable. It does not explicitly contrast itself with siblings like when_final or check_question, but the diagnostic-report framing is distinct enough in practice.
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 concrete triggering context for the tool, which is unusually clear guidance. It stops short of naming alternatives or stating when not to call it, so it falls 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.
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, and whether the record is stale.
| 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 safety and world-scope are covered. The description adds genuine behavioral value by disclosing the count-stage model (exit poll through government) with confidence/citation and a staleness flag. It does not say what makes a record stale, whether stale data is refreshed, or what happens with an unknown election id.
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 that leads with the core object ("Full record of one election") and then enumerates contents. It is list-heavy and slightly run-on, but every clause describes actual returned data rather than 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 the description need not re-explain return values — making its content enumeration partly redundant — while the input side is fully schema-documented. The real gap is selection context: nothing tells the agent how this differs from next_election, upcoming_elections, or when_final, which is the main thing left unaddressed.
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, and the schema documents it at 100% coverage including a format example ("latvia-parliamentary-2026"). The description adds no syntax, validity, or lookup guidance beyond the schema. Per the baseline for high schema coverage, 3 is appropriate.
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 — the full record of one election — and enumerates the substantive content (races, count-stage windows, authority, sources, vote counts, staleness). An agent can tell this returns a single election's detail record. It does not, however, explicitly contrast itself with siblings like next_election, upcoming_elections, or when_final, so differentiation is left to inference.
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 guidance and no named alternative. With siblings such as next_election, upcoming_elections, and when_final clearly overlapping in the election domain, the description never says when this single-election lookup is the right call instead of those, nor does it state prerequisites (e.g., needing a valid election id).
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 411 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 the safety profile is covered. The description adds real value beyond that: the coverage envelope (411 elections, 100 countries, 2021–2030) tells the agent when results may be empty, and the declared/tentative/expected distinction discloses data-reliability nuance. It still says nothing about rate limits or freshness guarantees beyond the 2024 US result.
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 purpose is front-loaded and each early sentence carries information. The final coverage sentence, however, is bloated and partly redundant, re-listing US coverage ('2026 US midterms in all 50 states', 'certified 2024 US presidential result ... in all 50 states and DC') in a way that serves marketing more than tool selection.
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 documentation is not required, yet the description still characterizes the payload (polling day, status, counting authority, expected results). Combined with the stated country/date coverage, an agent has enough to call it correctly; only the relationship to sibling tools like upcoming_elections or when_final is left implicit.
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 100%, so all three parameters are already documented, including the level enum values and the count default. The description largely restates the level default and the national/regional distinction rather than adding syntax or format detail, so the baseline 3 applies.
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 opening sentence names a specific resource and scope ('the next elections in one country, however far ahead') and enumerates exactly what is returned: polling day, declaration status, what is elected, counting authority, and expected results. The 'in one country' framing plus the national/regional distinction makes it separable from the plural sibling upcoming_elections without opening a 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?
Concrete question exemplars ('When is the next election in Austria?', 'When are the US midterms?') and an explicit rule that level='regional' is for 'When are the next state elections in Germany?' give clear context for when the tool applies. It never names an alternative tool or states when not to use it, 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.
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 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.
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.
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.
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.
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.
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.
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?
Annotations cover the safety profile (destructiveHint=false, openWorldHint=false, idempotentHint=false), and the description adds genuinely useful context beyond them: the report is public, it is checked like any other claim, and it never mutates data by itself. It stops short of noting auth needs or 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?
Three tight sentences, front-loaded with the action, then the evidence requirement, then the outcome and follow-up URL. Every sentence carries information; nothing is padding.
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?
Despite an output schema that would excuse omitting return details, the description still states the returned report id and where to follow it, and covers the public/moderation nature of the report. Nothing an agent needs to invoke it correctly 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?
Schema description coverage is already 100%, so the baseline is 3. The description adds meaning on top of that by prescribing the quality of the evidence parameter ('ideally the official authority page') and framing the claim parameter as 'what is wrong and what is right'.
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 a specific action and object: reporting a mistake or a missing election, backed by a proving URL. It is unambiguous about what the tool does, though it never distinguishes itself from the sibling tools by name or scope.
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 gives clear conditions for use (you have found a mistake or missing election) and a prerequisite (a URL that proves it), and clarifies the effect is review, not direct data change. No alternatives or when-not-to-use paths are offered, but the context is sufficient to select it.
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 411 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context: the default date-window logic that silently changes results, and dataset scope (411 elections, 2021–2030). It stops short of stating return shape or pagination, but that is acceptable given an output schema 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?
Front-loaded with purpose, sort order, and defaults before the example questions. The final coverage paragraph (EU members, US midterms, vote counts in 50 states) is marketing-flavored and slightly padded, but still conveys scope.
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 description covers purpose, defaults, scope, and example intents. It is largely complete for a 6-param optional-argument list tool, missing only explicit sibling disambiguation.
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% and each parameter already documents its default and format, so the description is not load-bearing here. It reinforces the default interactions between from/to/country but adds little syntax or semantics beyond the schema; baseline 3 is appropriate.
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 ('List elections') plus sort order ('soonest first') and an unusual added field (expected count stage). This distinguishes it from siblings like next_election (singular) and election_status.
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 example questions and, more usefully, the default resolution rules (no dates = today; country-only = all future; otherwise 365 days), which tell the agent how calls behave. It does not explicitly route against siblings such as next_election or election_status, so it falls 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.
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 safety is covered. The description adds genuine behavioral context beyond that: the confidence taxonomy (announced / precedent / estimate), that a historical precedent duration is returned, and that the final count may not yet be held. It does not disclose rate limits or freshness caveats, but the added value is real.
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, front-loaded with the core question and followed by the payload contents and usage directive; little waste. The output enumeration is dense but each item is informational, and the usage sentence earns its place.
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 values need not be spelled out, yet the description still summarizes the payload (window, confidence, basis, prior duration, count). Combined with the readOnly annotation and the usage directive, an agent has everything needed to call it 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 description coverage is 100%, so the schema already documents both 'election' (with example id and a pointer to upcoming_elections) and 'race' (with example and the optionality rule). The description adds no parameter-level syntax or meaning, so the baseline of 3 applies.
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 a specific resource and outcome — the window in which a race's final/certified result will exist — with a clear verb framing ("When will ... exist?"). It is readily distinguishable from siblings like election_status or next_election because it is about forecasting the certification date, not reporting current state.
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 gives explicit when-to-use guidance: "Use this before asking or settling any 'final result' question." That is clear context, but it names no alternative tool (e.g. election_status, resolution_sources) that an agent might otherwise reach for when a final result is already known.
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_question3 fields changedOutput schema / properties / result / properties / resolution_sources / items / properties / figures_in_htmlAdded 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"
+ ]
+}Output schema / properties / result / properties / resolution_sources / items / properties / oracle_readsAdded value: +{
+ "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / result / properties / secondary_sourceAdded value: +{
+ "description": "Global Election Index's own page with the count we recorded: a secondary source when the authority's page cannot be read. Null until a count is recorded.",
+ "properties": {
+ "copied_from": {
+ "description": "The authority file or page the figures come from",
+ "type": "string"
+ },
+ "final": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "description": "Publisher",
+ "type": "string"
+ },
+ "retrieved_at": {
+ "description": "When we read the count (ISO)",
+ "type": "string"
+ },
+ "stage": {
+ "description": "Count stage of the figures shown",
+ "type": "string"
+ },
+ "url": {
+ "description": "Race results page",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}election_status2 fields changedOutput schema / properties / result / properties / races / items / properties / sources / items / properties / figures_in_htmlAdded 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"
+ ]
+}Output schema / properties / result / properties / races / items / properties / sources / items / properties / oracle_readsAdded value: +{
+ "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+ "type": [
+ "object",
+ "null"
+ ]
+}next_election2 fields changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / sources / items / properties / figures_in_htmlAdded 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"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / sources / items / properties / oracle_readsAdded value: +{
+ "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+ "type": [
+ "object",
+ "null"
+ ]
+}resolution_sources2 fields changedOutput schema / properties / result / items / properties / figures_in_htmlAdded 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"
+ ]
+}Output schema / properties / result / items / properties / oracle_readsAdded value: +{
+ "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+ "type": [
+ "object",
+ "null"
+ ]
+}upcoming_elections2 fields changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / sources / items / properties / figures_in_htmlAdded 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"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / sources / items / properties / oracle_readsAdded value: +{
+ "description": "Settlement-oracle lab reads of this URL: right, wrong, unread, lab, at",
+ "type": [
+ "object",
+ "null"
+ ]
+}election_status3 fields changedOutput schema / properties / result / properties / date / descriptionPrevious value: -"Polling day (YYYY-MM-DD)"New value: +"Polling day (YYYY-MM-DD); for an expected date, the last day of date_window"Output schema / properties / result / properties / date_status / descriptionPrevious value: -"declared, scheduled or tentative"New value: +"declared, tentative, or expected (no day set yet: see date_window)"Output schema / properties / result / properties / date_windowAdded value: +{
+ "description": "Only for date_status \"expected\": the period polling day is expected in",
+ "properties": {
+ "from": {
+ "description": "First possible day (YYYY-MM-DD)",
+ "type": "string"
+ },
+ "label": {
+ "description": "How we name the period, e.g. \"Q2 2029\"",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "to": {
+ "description": "Last possible day (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}next_election3 fields changedOutput schema / properties / result / properties / elections / items / properties / date / descriptionPrevious value: -"Polling day (YYYY-MM-DD)"New value: +"Polling day (YYYY-MM-DD); for an expected date, the last day of date_window"Output schema / properties / result / properties / elections / items / properties / date_status / descriptionPrevious value: -"declared, scheduled or tentative"New value: +"declared, tentative, or expected (no day set yet: see date_window)"Output schema / properties / result / properties / elections / items / properties / date_windowAdded value: +{
+ "description": "Only for date_status \"expected\": the period polling day is expected in",
+ "properties": {
+ "from": {
+ "description": "First possible day (YYYY-MM-DD)",
+ "type": "string"
+ },
+ "label": {
+ "description": "How we name the period, e.g. \"Q2 2029\"",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "to": {
+ "description": "Last possible day (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}upcoming_elections3 fields changedOutput schema / properties / result / properties / elections / items / properties / date / descriptionPrevious value: -"Polling day (YYYY-MM-DD)"New value: +"Polling day (YYYY-MM-DD); for an expected date, the last day of date_window"Output schema / properties / result / properties / elections / items / properties / date_status / descriptionPrevious value: -"declared, scheduled or tentative"New value: +"declared, tentative, or expected (no day set yet: see date_window)"Output schema / properties / result / properties / elections / items / properties / date_windowAdded value: +{
+ "description": "Only for date_status \"expected\": the period polling day is expected in",
+ "properties": {
+ "from": {
+ "description": "First possible day (YYYY-MM-DD)",
+ "type": "string"
+ },
+ "label": {
+ "description": "How we name the period, e.g. \"Q2 2029\"",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "to": {
+ "description": "Last possible day (YYYY-MM-DD)",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}upcoming_elections1 field changedInput schema / properties / include_discovered / descriptionPrevious value: -"Also list elections found on Wikidata but not yet verified by Election Index"New value: +"Also list elections found on Wikidata but not yet verified by Global Election Index"election_status4 fields changedOutput schema / properties / result / properties / races / items / properties / results / items / properties / electorateAdded value: +{
+ "description": "Registered voters",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / result / properties / races / items / properties / results / items / properties / rows / items / properties / colourAdded value: +{
+ "description": "Party colour (#RRGGBB, from Wikidata)",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / races / items / properties / results / items / properties / rows / items / properties / party_idAdded value: +{
+ "description": "Wikidata QID of the party",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / races / items / properties / results / items / properties / turnoutAdded value: +{
+ "description": "Percent of registered voters who cast a ballot",
+ "type": [
+ "number",
+ "null"
+ ]
+}next_election4 fields changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / electorateAdded value: +{
+ "description": "Registered voters",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / colourAdded value: +{
+ "description": "Party colour (#RRGGBB, from Wikidata)",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / party_idAdded value: +{
+ "description": "Wikidata QID of the party",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / turnoutAdded value: +{
+ "description": "Percent of registered voters who cast a ballot",
+ "type": [
+ "number",
+ "null"
+ ]
+}upcoming_elections4 fields changedOutput schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / electorateAdded value: +{
+ "description": "Registered voters",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / colourAdded value: +{
+ "description": "Party colour (#RRGGBB, from Wikidata)",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / rows / items / properties / party_idAdded value: +{
+ "description": "Wikidata QID of the party",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / races / items / properties / results / items / properties / turnoutAdded value: +{
+ "description": "Percent of registered voters who cast a ballot",
+ "type": [
+ "number",
+ "null"
+ ]
+}when_final5 fields changedOutput schema / properties / result / properties / final_result / properties / electorateAdded value: +{
+ "description": "Registered voters",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / result / properties / final_result / properties / rows / items / properties / colourAdded value: +{
+ "description": "Party colour (#RRGGBB, from Wikidata)",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / final_result / properties / rows / items / properties / party_idAdded value: +{
+ "description": "Wikidata QID of the party",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / final_result / properties / turnoutAdded value: +{
+ "description": "Percent of registered voters who cast a ballot",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / result / properties / last_timeAdded value: +{
+ "description": "How long the final result took the last time this kind of race was held here",
+ "properties": {
+ "act": {
+ "description": "What the final act was",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "days": {
+ "description": "Days from polling day to the final act",
+ "type": "integer"
+ },
+ "election": {
+ "description": "That election, e.g. \"Bundestag 2025\"",
+ "type": "string"
+ },
+ "final_on": {
+ "description": "Day of its official final act",
+ "type": "string"
+ },
+ "polling_day": {
+ "description": "Its polling day",
+ "type": "string"
+ },
+ "source": {
+ "description": "Page showing the date",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source_kind": {
+ "description": "authority or press",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}election_status3 fields changedOutput schema / properties / result / properties / levelAdded value: +{
+ "description": "national or regional",
+ "type": "string"
+}Output schema / properties / result / properties / subdivisionAdded value: +{
+ "description": "ISO 3166-2 code of the state or region, if the election belongs to one",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / subdivision_nameAdded value: +{
+ "description": "Name of that state or region",
+ "type": [
+ "string",
+ "null"
+ ]
+}next_election7 fields changedInput schema / properties / levelAdded value: +{
+ "description": "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",
+ "enum": [
+ "national",
+ "regional",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / result / properties / elections / items / properties / levelAdded value: +{
+ "description": "national or regional",
+ "type": "string"
+}Output schema / properties / result / properties / elections / items / properties / subdivisionAdded value: +{
+ "description": "ISO 3166-2 code of the state or region, if the election belongs to one",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / subdivision_nameAdded value: +{
+ "description": "Name of that state or region",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / levelAdded value: +{
+ "description": "national, regional or all",
+ "type": "string"
+}Output schema / properties / result / properties / regional_upcomingAdded value: +{
+ "description": "Upcoming regional elections in this country (with level national); ask again with level \"regional\"",
+ "type": "integer"
+}Output schema / properties / result / properties / total_upcoming / descriptionPrevious value: -"All upcoming elections we list for this country"New value: +"All upcoming elections we list for this country at this level"upcoming_elections4 fields changedInput schema / properties / levelAdded value: +{
+ "description": "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",
+ "enum": [
+ "national",
+ "regional",
+ "all"
+ ],
+ "type": "string"
+}Output schema / properties / result / properties / elections / items / properties / levelAdded value: +{
+ "description": "national or regional",
+ "type": "string"
+}Output schema / properties / result / properties / elections / items / properties / subdivisionAdded value: +{
+ "description": "ISO 3166-2 code of the state or region, if the election belongs to one",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / result / properties / elections / items / properties / subdivision_nameAdded value: +{
+ "description": "Name of that state or region",
+ "type": [
+ "string",
+ "null"
+ ]
+}UK GCSE and A-level exam dates, results days, entry deadlines and spec changes.
Living, source-backed timelines of long-running events, with a quote and source per entry.
When are elections held in a Japanese prefecture? Official dates relayed, official page URL first.
Crypto events calendar: dated, sourced and impact-scored events for 14,000+ coins.
Add one secure layer between your agents and this server.