Knesset 2026 · how far to 61

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

Annotations already cover the safety profile (read-only, idempotent, closed-world, non-destructive), so the description is not burdened with basic safety disclosure. It adds meaningful behavioral context by explaining that the output includes red-line pairs with quotes and sources, historical coalition government instances, and the caveat that it is a logic aid rather than a forecast.

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 description is front-loaded with the core result: seats and whether the parties reach 61. It then efficiently lists the red-line and historical-government details, followed by a compact caveat. Every sentence adds useful information with no 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?

With no output schema, the description carries the burden of explaining return values, and it does so by naming seats, threshold status, red lines with quotes/sources, and past coalition government elections. It is complete enough for an agent to understand the tool's scope, though it does not specify exact output structure or data freshness.

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 schema already documents the parties array and lang enum. The description does not add syntax, format, or selection guidance beyond what the schema provides, so the baseline score of 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 clearly states what the tool returns: seats for a set of parties, whether they reach 61, mutual red lines with quotes and sources, and past coalition government history. It is specific about the resource and operation, but it does not explicitly differentiate itself from siblings such as get_formation or get_formation_history.

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 name and description: use it to test a hypothetical coalition's seats and red lines. The caveat 'A logic aid, not a forecast' gives useful interpretive guidance, but the description never names alternatives or states explicit when-to-use/when-not-to-use conditions versus sibling tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the scope restriction to 'regular ballot boxes' and the provenance ('CEC final results'), which tells the agent what data is and isn't included.

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 core purpose and the returned payload before the search mechanics, with no filler. It is a long run-on list, but each clause carries distinct information about the result set.

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 no output schema, the description does the work of enumerating return values, which is the right call. The one gap is that it doesn't say whether a name query returns a single town or a list of matches — relevant for a tool named 'find'.

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 the description's mention of four search languages and CBS codes largely restates the query and lang parameter documentation. It adds no syntax, normalization, or fallback behavior beyond what the schema already states, so 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?

States a specific resource ('how a town, village or kibbutz voted') and enumerates exactly what the result contains: vote shares, hypothetical Knesset, most-similar town, CBS cluster, and first-place list since 2003. This is clearly distinct from every sibling (coalition, formation, news, results, wealth, what-can-change), none of which are locality lookups.

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 explains how to query ('search by name in Hebrew, English, Russian or French, or by CBS locality code') but never says when to reach for this versus a sibling like get_results, nor any when-not condition. Usage is implied by the resource scope rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new behavioral context: only recommendations backed by at least one feed source that nothing contradicts are surfaced, and declarations are restricted to those made before the consultations — this tells the agent how trustworthy and how current the data is.

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, correctly front-loaded with the scoping clause 'Where forming the government stands:' followed by the payload list. Every listed item is substantive rather than filler, though the colon-and-list construction is slightly heavy for one sentence.

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 no output schema, the description carries the burden of explaining return values, and it does so item by item (stage, recommendations, declarations, mandate, deadline). Combined with annotations that cover the read-only/idempotent profile and a fully documented single parameter, an agent has enough to call it correctly; only the current-vs-historical boundary 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?

There is a single optional parameter with 100% schema description coverage and an enum, so the schema fully documents it. The description adds nothing about language behavior or defaulting, so the baseline of 3 for high coverage 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 verb-plus-resource is implicit but unambiguous: 'Where forming the government stands' names the exact subject and then enumerates the payload (stage, confirmed recommendations, leaders' declarations, mandate and deadline). An agent can tell it apart from get_formation_history and check_coalition by the current-state framing, though the description never explicitly contrasts them.

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 only implied — an agent infers it should call this when it needs the present state of government formation. There is no explicit when-to-use or when-not-to-use statement and no mention of the sibling alternatives (get_formation_history, check_coalition) that an agent might confuse it with.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that the description adds genuine context: the data source (ParlGov), the historical depth (1949 onward), and the exact facts returned per election (confidence-vote day, duration, rotation, dissolution when no government formed). It doesn't cover response shape or size, but for a read-only reference tool this is solid added value.

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?

Scope is front-loaded ('Every Knesset election since 1949'), which is good, but the whole definition is one sprawling semicolon-chained sentence mixing election data, government composition, and pairwise party co-governance. Parsing it costs effort; splitting the pairwise-co-governance clause into its own sentence would help at no length cost.

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?

No output schema exists, so the description has to carry return-value semantics — and it does, enumerating the per-election fields and the pairwise co-governance dimension. The only gap is that it doesn't characterize the shape of the response (one record per election? one row per pair?) or its approximate size.

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?

There is a single parameter (lang) with 100% schema description coverage and an enum of four languages, so the schema fully documents it. The description never mentions the language parameter or what localization affects (names vs. narrative text). Baseline 3 is appropriate when the schema does all the work.

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 exact resource — every Knesset election since 1949, the first government after it, confidence votes, prime minister and rotation, parties holding ministries — so an agent knows precisely what corpus this returns. It doesn't name the sibling get_formation as the current-formation alternative, but the closing 'History, not a forecast' does scope it against a live/forecast tool. Clear and specific, just short of explicit sibling routing.

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 rather than stated: 'History, not a forecast' tells the agent this is retrospective data, and the pairwise 2026-party co-governance element hints at a coalition-history use case. There is no explicit 'use this when…, use X instead' sentence and no mention of when the tool would be the wrong choice relative to get_formation or check_coalition.

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

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

Annotations already declare read-only, idempotent, closed-world behavior, so the safety profile is covered. The description adds real domain context beyond that: the data source (Knesset Spokesperson), the snapshot nature of the dataset, the edge case of unelected outgoing ministers seated at the government table, and the inclusion of candidates who resigned before the oath, with sources.

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

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

It is front-loaded with the dataset identity and then the two output modes, with no filler. The single dense semicolon-chained sentence is slightly run-on and could be split for easier parsing, keeping it off a 5.

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 no output schema and only two optional parameters, the description carries the burden of explaining returns and does so adequately: seat, adjacent seats, list and place, plus the block listing and the special government-table case. It does not mention response size or whether the source citations are inline, but nothing essential to calling 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 coverage is 100%, so baseline is 3, but the description adds semantics the schema does not: omitting 'name' changes the response into a whole-hall block listing rather than an error or empty result. Language handling is already fully documented in the schema, so no extra credit there.

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 scope: the seating plan of the 26th Knesset plenum for its swearing-in, and states exactly what is returned in each mode (a member's seat with neighbours and list placement, or every block of the hall). No sibling tool touches seating, so an agent can route here without opening the 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 clearly distinguishes the two invocation modes: supply a name to get one member's seat, omit the name to get every block of the hall. That is concrete mode-selection guidance. It stops short of naming alternatives or stating exclusions (e.g. that this covers only the 26th Knesset), 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.

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful behavioral context by disclosing the curation rule and the machine-translation caveat, though it omits rate limits, pagination, and return-shape details.

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 definition is a single compact sentence that front-loads the main resource and then adds relevant qualifiers. There is no redundant or filler language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with full schema descriptions and strong annotations, the description is largely complete: it explains feed composition and translation caveats. It still leaves the exact return shape and ordering implicit, which is a minor gap without an 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 lang and limit are already documented with defaults and constraints. The description adds no parameter-specific detail beyond a general mention of machine translation, 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 description clearly identifies the resource as the site's latest feed posts and specifies whose posts they are, making the tool's purpose understandable. It does not explicitly differentiate itself from the sibling political-data tools, so it falls short of a 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?

The description implies usage by framing the tool as the source for the latest posts from political figures and journalists. However, it gives no explicit guidance on when to choose this tool over siblings such as get_results or get_formation, and no exclusions.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the safety bar is low. The description adds genuinely new behavioral context the annotations cannot: results are preliminary until the CEC publishes the official count, and bloc assignment is an editorial mapping rather than official data — both affect how much an agent should trust the numbers.

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?

One dense sentence with no filler, and the content inventory leads. The parentheticals (editorial mapping, CEC publication) are load-bearing rather than padding, though the sentence is delivered as a noun phrase rather than a statement of what the tool does.

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 no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing the four data families. What remains unstated is the response shape (per-list objects, totals, ordering), which an agent would have to discover by calling.

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?

There is a single optional lang parameter with an enum, and schema coverage is 100%, so the schema fully documents it. The description says nothing about language handling, which is acceptable at the baseline but adds no value beyond structured data.

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 the exact payload — seats and votes per list, the 3.25% threshold, bloc mapping, and count status — which is far more specific than the title 'Election results'. It doesn't name a verb or explicitly contrast with siblings like check_coalition or get_what_can_change, but the resource is unambiguous and distinct from them.

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 only implied: an agent can infer this is the tool for the tally itself, but there is no when-to-use statement, no mention of when to prefer check_coalition or get_what_can_change instead. The note that results are preliminary until the CEC publishes is the only decision-relevant guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive safety, and the description adds real context beyond them: the cluster index vintage (2021), the pairing scheme (1–2 … 9–10), what each row measures (share of valid votes), and the unit-of-analysis warning. It does not describe ordering or how blocs are keyed, but for a no-param aggregate read this is substantive.

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 dense sentences, front-loaded with what is returned, followed by the interpretive caveat. Every clause carries information; 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?

With no output schema and no parameters, the description must convey the return content, and it does (bloc → share of valid votes). The main omission is the election/timeframe being aggregated, which an agent would want before trusting the numbers; ordering and bloc labels are also unstated.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description usefully fixes the grouping semantics (paired deciles 1–2 through 9–10, index 2021), which the empty schema obviously cannot convey.

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+resource: the vote of Israel's municipalities grouped by CBS socio-economic cluster, with each bloc's share of valid votes. It implicitly separates itself from raw-result siblings (get_results) by the grouping and the 'describes places, not voters' framing, but never names an alternative explicitly.

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

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

There is no explicit when-to-use or when-not clause and no sibling is named, so the agent must infer that this is the analytical/aggregate view versus get_results or check_coalition. The closing caveat 'Describes places, not voters' does imply a constraint on interpretation (don't read it as voter-level data), which is more than nothing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety needs no restating. The description adds useful content scope, notably that results include status and sources for tracked cases, but says nothing about volume, freshness, or whether 'distance to 61' is a count or a margin.

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

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

It is a single sentence with no filler, but it is a dense parenthetical pile-up that buries the primary subject behind two competing topic clusters. Front-loading the 'what changes' computation ahead of the complaints list would help.

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 no output schema, the description must carry return semantics, and it does sketch the fields returned. However, terms like 'distance to 61' and 'nearest seat each way' remain unexplained, so an agent cannot fully predict response shape or units.

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 optional parameter (lang) with a fully covered schema description including the enum and the 'default en' note. The description adds nothing about language handling, but with 100% schema coverage 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 does enumerate the content returned (seat-change votes, bloc distance to 61, nearest seats, tracked complaints/inquiries/cases/appeals), but the tool name 'get_what_can_change' is abstract and the sentence fuses two unrelated data sets (electoral arithmetic and case tracking) without saying what the resource actually is. An agent can guess the payload but cannot confidently distinguish it from check_coalition or get_formation.

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 statement of when to call this versus the clearly related siblings (check_coalition, get_results, get_formation), and no prerequisites or exclusions. The agent must infer usage entirely from the payload list.

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