MCP Assemblée nationale

Comment A Vote

comment_a_vote

Read-onlyIdempotent

Look up how a French deputy voted on a topic or specific vote, including their position (for, against, abstention, non-voting) and source links.

Instructions

Répond à « Comment a voté le député X sur le sujet Y ? ».

Indiquer depute et soit sujet, soit scrutin_uid. Retrouve le député (si le nom est ambigu, liste les candidats pour que l'utilisateur choisisse), puis donne sa position (pour, contre, abstention, non-votant) sur les 5 premiers scrutins correspondant au sujet, avec les liens sources. Un sujet donne souvent plusieurs scrutins (amendements, articles, ensemble du texte) : citer le titre de chacun. Aucune interprétation. La législature vaut 17 par défaut ; elle se déduit de scrutin_uid s'il est donné (14e à 17e législature).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "depute": "<depute>"
    },
    "name": "comment_a_vote"
  }
}

Input Schema

Name	Required	Description
`sujet`	No	Sujet du vote en mots-clés (« retraites », « budget »), avec accents.
`depute`	Yes	Nom du député (« Marine Le Pen », « Panot ») ou son `uid`.
`legislature`	No	Législature : 17 par défaut ; les 14e, 15e et 16e sont aussi couvertes.
`scrutin_uid`	No	Identifiant d'un scrutin précis, à la place de `sujet`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavior: ambiguity triggers a candidate list rather than a guess, results are capped at the 5 first matching scrutins, source links are included, and no interpretation is given. The cap and the no-interpretation rule are the kind of expectation-setting an agent needs; return payload shape is only partly described.

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?

Front-loaded with the question it answers, followed by the workflow, output description, and defaults – each sentence carries information. It is on the longer side for a 4-parameter tool, with some repetition between the description and the already-verbose schema defaults.

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

Completeness5/5

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

There is no output schema, and the description compensates fully: it names the position vocabulary (pour, contre, abstention, non-votant), the result limit, the inclusion of source links and titles, and the legislature default. An agent can call this correctly and predict the response without further information.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter logic the schema cannot express: `sujet` and `scrutin_uid` are alternatives, and `legislature` defaults to 17 yet is deduced from `scrutin_uid` when present. It also clarifies `depute` accepts a name or a uid.

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?

Opens with the exact user question it answers ('Comment a voté le député X sur le sujet Y ?'), then names the verb and resource: resolve the deputy, then return their position on matching scrutins. This is clearly distinct from siblings like obtenir_scrutin, votes_scrutin and bilan_depute, which do not combine deputy + subject resolution.

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?

Explicit conditional usage: give `depute` and either `sujet` or `scrutin_uid`, list candidates when the name is ambiguous, and cite each scrutin title because a subject maps to several votes. It does not explicitly say when to prefer a sibling (e.g. obtenir_scrutin for a single known scrutin), which keeps it just below a 5.

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