André — Analyse électorale française

Résultats électoraux

query_elections

Read-onlyIdempotent

Requête les données électorales françaises (1999-2026).

    Niveaux territoriaux : NATIONAL (aucun filtre), RÉGIONAL (region_code),
    DÉPARTEMENTAL (departement_code), COMMUNAL (commune_code).

    Actions de base : list_elections, query_results, list_bureaux, query_bureau,
    query_by_bureau, rank_bureaux, list_circonscriptions, query_circonscription,
    list_cantons, query_canton, search_candidate, query_candidatures, etc.

    Actions « panel » (1 appel = analyse complète, évite les boucles) :
    - compare_elections : compare deux scrutins pour un territoire
      (election_id + compare_to_election + commune_code|departement_code,
      candidate_name optionnel).
    - query_all_circonscriptions : vainqueur de CHAQUE circonscription d'un
      territoire en un appel (election_id + commune_code|departement_code,
      législatives uniquement).
    - vote_reserve : score d'une famille + abstention par bureau de vote sur
      les scrutins récents comparables (commune_code + famille).
    - select_communes : sélectionne/classe des communes par critères géo +
      population + électoraux (region_code/departement_code/epci/commune_codes,
      population_min/max, commune_metric, condition, sort_by, limit, order ;
      commune_metric/condition nécessitent election_id). commune_metric accepte
      PLUSIEURS métriques séparées par des virgules — une colonne chacune, en
      un seul appel ; condition et sort_by portent alors sur la première.
    - cross_election_panel : évolution d'un sujet (famille ou nuance_code) par
      commune sur N scrutins (elections=ids séparés par des virgules + scope
      optionnel commune_code/departement_code/region_code/commune_codes ;
      SANS scope = national, panel complet en data_file). Renvoie aussi
      « ensemble » : score du périmètre entier par scrutin + delta, pondéré
      par les exprimés — ne pas boucler par département. famille et nuance_code
      acceptent PLUSIEURS sujets séparés par des virgules ('Gauche,Droite') :
      tous en un appel, agrégats dans « ensembles ». group_by='region'|
      'departement' ajoute un agrégat pondéré PAR MAILLE dans le même appel —
      ne jamais boucler un appel par région.
    - bureau_breakdown : pivot par bureau (top_n nuances/blocs + participation,
      with_sociodem optionnel) pour commune_code + election_id.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`epci`	No
`tour`	No
`limit`	No
`order`	No
`top_n`	No
`action`	Yes
`offset`	No
`famille`	No
`sort_by`	No
`group_by`	No
`bureau_id`	No
`by_family`	No
`condition`	No
`elections`	No
`bureau_code`	No
`canton_code`	No
`election_id`	No
`family_name`	No
`list_search`	No
`nuance_code`	No
`rank_metric`	No
`region_code`	No
`commune_code`	No
`nuance_level`	No
`scrutin_type`	No
`commune_codes`	No
`with_sociodem`	No
`candidate_name`	No
`commune_metric`	No
`population_max`	No
`population_min`	No
`candidate_query`	No
`use_ferd_coding`	No
`candidate_search`	No
`departement_code`	No
`compare_to_election`	No
`circonscription_code`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which is consistent with the description. The description adds valuable behavioral context beyond annotations: performance guidance around avoiding loops, aggregation semantics for 'ensemble', comma-separated multi-subject handling, and data_file output behavior. No contradiction exists.

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

Conciseness4/5

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

The description is long but densely organized: purpose first, then territorial levels, then basic actions, then panel actions with bulleted explanations. It is front-loaded and every major section adds necessary information for a very complex 37-parameter tool. Minor redundancy exists in repeating the 'ne pas boucler' guidance, but it is not wasted.

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

Completeness3/5

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

The panel actions are described in detail, but basic actions such as query_results, list_bureaux, and search_candidate are only listed by name without their required parameter combinations. Given the high parameter count and lack of schema descriptions, this leaves an agent to guess the exact invocation contract for many common operations. The presence of an output schema helps return-value understanding, but not input construction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the full burden for parameters, and it does substantial work: it maps action names to relevant parameter combinations, explains required dependencies (e.g., commune_metric/condition nécessitent election_id), and documents comma-separated multiple-value behaviors. Still, not all 37 parameters are explained, and some like use_ferd_coding and by_family remain ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Requête les données électorales françaises (1999-2026)'. It clearly distinguishes this tool from siblings like query_elus and query_sociodem by its electoral-data scope and enumeration of specific actions.

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

Usage Guidelines4/5

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

The description gives clear usage context for each major action class, especially for 'panel' actions, explaining when they are useful ('1 appel = analyse complète, évite les boucles') and even what not to do ('ne pas boucler par département'). However, it does not explicitly state when this tool should be preferred over sibling tools like query_sql, so exclusion guidance is somewhat implicit.

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

All André — Analyse électorale française tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation4/5

The query_* tools are mostly cleanly separated by domain (elections, admin, DLP, élus, sociodem), and the output-oriented tools (map, table, visualization, export) are distinct. The main potential confusion is query_sql versus query_elections, since both can access election results, but the descriptions mitigate this by explicitly recommending query_elections for standard analysis.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb-first convention: query_* for data retrieval, and create_data_table, export_data, generate_map, simulate_fusions, and visualize for actions. There is no mixing of camelCase, inconsistent verb styles, or vague duplicate-like naming.

Tool Count5/5

With 11 tools, the server is well within the ideal scope for a specialized electoral analysis toolset. Each query tool covers a coherent data domain, while mapping, visualization, export, table formatting, and simulation cover distinct workflow needs without redundancy.

Completeness5/5

The tool surface covers the full electoral analysis workflow: querying results and administrative divisions, socio-demographic profiles, elected officials, municipal candidate data, mapping, custom visualizations, tabular formatting, export, and fusion simulation. The advanced panel actions in query_elections plus the read-only SQL fallback fill most conceivable gaps.

Résultats électoraux

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources