Sondages présidentielle 2027 agrégés : moyennes, marges, tendances, duels.
Scored across 5 tools
The four aggregate tools (polling average, runoff polls, trend, recent polls) target reasonably distinct views — ranking snapshot, second-round matchups, time series, and raw poll records. However, get_candidate is explicitly a superset that bundles a candidate's average, evolution, runoff duels, and individual polls, so it overlaps with every other tool and agents may default to it or misselect between it and get_trend/get_runoff_polls. Descriptions mitigate this by clarifying scope, but the boundaries are not clean.
All five tools follow a consistent snake_case verb_noun pattern (get_candidate, get_polling_average, get_runoff_polls, get_trend, list_recent_polls). The get_ vs list_ distinction is used meaningfully — list_ for raw records, get_ for aggregates — making the pattern predictable.
Five tools is well-scoped for a focused polling dataset, mapping cleanly to the main access patterns: single candidate, first-round ranking, runoff matchups, time series, and raw poll list. No tool feels redundant or padded.
Core lifecycle is covered: candidate-level aggregation, first-round averages, runoff measurements, trends, and raw recent polls, with the ranking tool implicitly listing candidates. Minor gaps remain — no way to retrieve a single poll by identifier, filter polls by institute or date range, or reference historical election results — but these are workarounds, not blockers.
Tout ce que les sondages disent d'un candidat : moyenne de premier tour, évolution, duels de second tour mesurés et sondages individuels où il figure.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Période de l'historique : 3m = 3 mois, 6m = 6 mois, 1a = 1 an, tout = Tout. Par défaut 6m. | |
| candidate | Yes | Nom du candidat, par exemple « Jordan Bardella ». Accents facultatifs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by enumerating the four content blocks the response contains (average, evolution, runoff duels, individual polls), which matters because there is no output schema. It does not mention response size or the default history window, which is the only notable 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?
A single compact sentence that front-loads the scope (« Tout ce que les sondages disent d'un candidat ») and then enumerates the payload. No filler, nothing repeated from 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?
With only two fully-documented parameters and no output schema, the description carries the burden of explaining what comes back, and it does so by naming the four result sections. Complete enough to call correctly; only the window default and any volume/limit expectations are absent.
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%: both `candidate` (name, optional accents) and `window` (3m/6m/1a/tout, default 6m) are fully documented in the schema. The description adds no parameter-level detail, 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 states precisely what is returned for a candidate: first-round average, evolution, measured second-round duels, and the individual polls the candidate appears in. That is a clear verbless but specific resource+content statement an agent can act on. It does not, however, differentiate itself from siblings like get_polling_average or get_trend, which cover a subset of the same content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase « Tout ce que les sondages disent d'un candidat » implies this is the one-stop aggregate and that the sibling tools are narrower slices, but that routing logic is left to inference. No explicit when-to-use or when-to-prefer-a-sibling statement is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classement de premier tour de la présidentielle française 2027 (French presidential election polls) : moyenne pondérée des sondages récents, marge d'erreur, tendance par candidat et évolution sur 6 mois.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds what the payload actually contains (weighted average, error margin, trend, 6-month evolution), which is valuable since no output schema exists, though it omits data freshness, update cadence and weighting methodology.
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 names the resource before the payload details. The bilingual parenthetical translation is slightly noisy but functional and adds clarity for non-French agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter aggregate with no output schema, the description is nearly complete: it conveys the domain, the computation and the returned fields. Remaining gaps are freshness and how the weighted average is derived.
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. Baseline 4 applies; the description correctly implies the call needs no arguments.
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 computation: the first-round ranking of the French 2027 presidential election, with the weighted average of recent polls, margin of error, per-candidate trend and 6-month evolution. 'Premier tour' implicitly separates it from get_runoff_polls, but no sibling is named 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?
Usage is only implied: an agent can infer this is the aggregate view for the first round, distinct from raw polls. There is no explicit when-to-use guidance or named alternative (e.g. get_trend, list_recent_polls) to route between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Face-à-face de second tour réellement mesurés par les instituts, avec marges et écart significatif ou non. Aucune projection ni report de voix.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds non-obvious content context: only actually measured duels are returned, with margins and a significant/not-significant gap indicator, and no projections — which shapes how an agent should interpret the results.
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 compact sentences: the first defines the data returned, the second immediately rules out the main misinterpretation. No filler, front-loaded, and every clause carries meaning.
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 parameterless, non-destructive read with no output schema, the description adequately conveys what the data is and what it contains (margins, significance). It omits the scope of coverage — which elections/periods and how many duels are returned — which would help an agent know what to expect.
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 and the schema is empty with additionalProperties=false, so there is nothing for the description to explain. Baseline 4 applies; no parameter ambiguity exists.
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 — second-round runoff head-to-head polls actually measured by polling institutes, with margins and significance — which clearly differentiates it from an averaged or trend view. It is clear without naming the sibling tools directly.
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?
"Aucune projection ni report de voix" explicitly excludes projections and vote transfers, so the agent knows to use this only for raw measured duels and to look elsewhere for modeled/second-round projections. It stops short of naming get_polling_average or get_trend as the alternatives, so routing is partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Évolution des moyennes de premier tour dans le temps, par candidat, avec la marge à chaque relevé.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Période de l'historique : 3m = 3 mois, 6m = 6 mois, 1a = 1 an, tout = Tout. Par défaut 6m. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's added value is telling the agent what the payload contains (per-candidate averages plus margin at each data point), which matters since there is no output schema. It says nothing about granularity, sort order, or how sparse the series may be.
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 sentence with no filler, and the core concept (evolution over time) is front-loaded. Every clause adds a distinct fact: dimension (candidate), and per-reading margin.
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-only tool with complete annotations, the description covers the content but leaves two gaps: it never references the `window` parameter, and 'la marge' is ambiguous (margin of error vs. lead margin) for a tool that returns per-candidate values. Adequate overall but not fully self-sufficient.
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%: the single enum `window` is fully documented with all four values and the 6m default. The description never mentions the time window, so it adds nothing beyond the schema. Baseline 3 applies when the schema carries the parameter 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 names a specific resource and shape: first-round polling averages over time, broken down by candidate, with the margin at each reading. An agent can tell this is a time-series view rather than a single snapshot. It stops short of naming `get_polling_average` as the point-in-time sibling, so sibling differentiation is only implicit.
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 is implied by the word 'évolution ... dans le temps' – the agent can infer this is the trend view versus the snapshot view. However, there is no explicit 'use this when X, use get_polling_average when Y' routing, and no prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sondages individuels récents de premier tour : institut, commanditaire, dates de terrain, échantillon, hypothèse testée et résultats bruts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and non-destructive, so safety is covered. The description usefully enumerates the fields returned (institut, commanditaire, dates de terrain, échantillon, hypothèse, résultats bruts), which matters because there is no output schema, but it says nothing about how many polls are returned or what 'récents' means in time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence, with the scope ('récents de premier tour') first and the returned fields after. 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?
Since there is no output schema, listing the result fields is genuinely compensating, but for a no-parameter list tool the agent still cannot tell the recency window, the result ordering, or the likely result volume. Adequate but with real gaps.
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 4 applies. The schema also forbids additional properties, consistent with taking no 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?
Names the resource precisely and scopes it: 'Sondages individuels récents de premier tour', plus the fields it surfaces. The 'premier tour' / 'individuels' framing implicitly separates it from get_runoff_polls and get_polling_average, but it never names those siblings 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?
No statement of when to use this versus get_polling_average, get_trend or get_runoff_polls. 'Récents' is the only selection cue and it is undefined (no window, no count).
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.
get_candidateget_polling_averageget_runoff_pollsget_trendlist_recent_pollsDéclarations sourcées des candidats à la présidentielle française 2027 (lecture seule).
Résultats des élections françaises 1999-2026 par bureau de vote, socio-démo INSEE et cartes.
Calcul fiscal (IR, IFI, PER, plus-value) et retraite français — 32 régimes, sourcé et daté.
Calcul fiscal et retraite français, déterministe et sourcé. Aucun conseil.
Add one secure layer between your agents and this server.