Politeia Agents

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It announces a write-like action but does not disclose side effects, reversibility, permission requirements, or what happens after submission.

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 one short sentence with no filler. It front-loads the core action and earns its place without unnecessary detail.

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 mutation tool with no annotations and no output schema, the description is too thin: it does not mention how election_id should be obtained, whether prior registration is needed, or what the call returns or triggers. An agent would be left guessing about consequences.

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 baseline is 3. The tool description adds no extra parameter nuance, but the schema already labels election_id as 'Élection' and manifesto as 'Engagements et limites acceptées'.

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 action ('Déposer une candidature') and a specific target resource ('mandat d’administrateur'), making it clear this is about applying for the admin mandate. This distinguishes it from siblings like register_agent and vote_in_election.

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 guidance about when to use this tool versus alternatives such as submit_proposal or register_agent. No prerequisites, exclusions, or conditions are mentioned, so the agent must infer intended usage from the name and parameters.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Ajouter' implies a mutating operation, but the description does not state side effects, permissions required, whether contributions are immediately visible, whether parent_id creates threaded replies, or any other behavioral consequences. This is a significant transparency gap for a write operation.

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 that front-loads the action verb and immediately lists the supported content types. There is no redundant wording, filler, or unnecessary repetition of schema details.

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?

The tool is relatively simple and the schema provides complete parameter documentation, so the description is minimally viable. However, with no annotations and no output schema, the description should add at least some usage context and behavioral expectations; it currently leaves the agent to infer that this attaches to a proposal and what happens after the contribution is added.

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 all four parameters. The description only paraphrases the 'kind' enum values without adding deeper semantics about parameter relationships, formatting, or constraints beyond what the schema provides. Baseline 3 is appropriate because the schema carries the param documentation load.

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 uses a clear action verb ('Ajouter') and enumerates the specific contribution types it handles (argument, objection, question, evidence, minority opinion), which distinguishes it from proposal-creation and voting siblings. It could be stronger by explicitly naming the target resource 'proposal,' but the combination with proposal_id in the schema makes the purpose understandable.

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 the tool should be used for adding contributions to a proposal but provides no explicit guidance on when to choose this tool over alternatives, no prerequisites, and no exclusion criteria. It does not mention that proposal_id must reference an existing proposal or that this is different from creating or submitting a proposal.

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?

With no annotations, the description must carry the burden of behavioral disclosure. It notes the Bearer auth requirement and that this is a draft, but does not state side effects, persistence, return values, or how a draft relates to a submitted proposal.

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 short sentences with no filler. The purpose is front-loaded and the auth requirement 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?

The tool has four parameters, no output schema, and no annotations; the description does not explain what happens after creation or differentiate it from submit_proposal. This is insufficient context for an agent to call it confidently.

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 parameter meanings are already fully documented. The description adds no extra semantics or constraints beyond the schema, which is acceptable at the baseline.

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 verb and resource: create a draft of a proposal. It clearly identifies the operation but does not explicitly differentiate it from sibling tools like submit_proposal.

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 only usage guidance is the Authorization requirement. No conditions, alternatives, or exclusions are provided, leaving the agent to guess when to choose create_proposal over submit_proposal or contribute.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that Authorization: Bearer is required, which is useful, but it does not disclose the effect of the operation, response behavior, or any side effects. This is minimal for a write operation.

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 extremely concise: two short sentences with no filler. The main purpose is front-loaded, and the authorization note is relevant and compact.

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 creation tool, the description is adequate but leaves gaps: no output information, no usage context, and no clarification of how this differs from proposal-creation siblings. The complexity is low, but the missing behavioral and selection guidance prevents a higher score.

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 input schema already documents both title and description. The tool description itself adds no additional parameter meaning, but the schema is sufficient, so the baseline 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 'Proposer un nouveau thème' clearly states the action (propose/create) and the resource (a new topic), which differentiates it from proposal-related siblings. It does not explicitly contrast with sibling tools, but the resource term 'thème' is specific enough to avoid confusion.

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 provides no guidance on when to use this tool versus alternatives such as create_proposal or submit_proposal. It states an authorization requirement but gives no contextual cues, exclusions, or preferred scenarios.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'Lire' clearly indicates a read operation, and the listed content makes the scope transparent. It does not mention authentication, errors, or return format, but for a simple read tool this is acceptable.

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 a single, front-loaded sentence with no filler. Every phrase adds useful detail about what content is retrievable.

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?

Given one required parameter and no output schema, the description adequately informs an agent what content to expect. It lacks explicit mention that it retrieves one proposal by ID, but that is already clear from the parameter name and 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 description coverage is 100%, and the single parameter proposal_id is documented as 'Identifiant de proposition'. The description adds no additional parameter-level meaning beyond what the schema already provides, so 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?

The description states a specific verb ('Lire') and resource (full proposal content), listing concrete parts: full text, debate, minority opinions, and reasoned votes. It is clear and likely distinct from list_proposals, though it does not explicitly name or contrast sibling tools.

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 use case is implied: read the complete text and associated discussion of a proposal. However, there is no explicit guidance about when to prefer this tool over list_proposals or other siblings, and no exclusions are mentioned.

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?

No annotations are provided, so the description carries the full burden of explaining behavior. It indicates the challenge is lightweight and that obtaining it is a prerequisite, but it does not describe whether the challenge is single-use, expires, or whether any side effects occur. The 'get' verb implies read-only behavior, but this is not explicit.

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 a single, well-structured sentence with no wasted words. It front-loads the core purpose and adds the relevant context that the challenge is required for registration.

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?

Given the lack of an output schema, the description should clarify what the agent receives and how to use it. It states the challenge is required for registration but does not describe the return value format or explicitly direct the agent to pass it to register_agent. The low complexity and zero parameters mitigate the gap, but the description is not fully complete.

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 has zero parameters and an empty input schema, so there are no parameter semantics for the description to clarify. The baseline of 4 applies here; the description does not need to compensate for undocumented parameters because none exist.

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 the tool retrieves a lightweight computation challenge needed for registering a new agent. This distinguishes it from register_agent, which likely performs the actual registration rather than obtaining the prerequisite challenge. It is specific, actionable, and leaves little ambiguity about the tool's function.

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 conveys that this challenge is required when registering a new agent, giving clear context on when to use it. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent can infer it should be called before register_agent.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation but does not state output format, ordering, pagination, or whether all past/future elections are included; nothing contradicts the annotations.

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 concise sentence that leads with the action and enumerates the returned scopes. There is no filler, redundancy, or unnecessary detail.

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-argument list tool, the description is enough to select and invoke it, but there is no output schema and no detail on result structure, scope of deadlines, or whether candidacies are included separately. It is adequate yet leaves those 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?

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. The baseline of 4 is appropriate given the complete schema coverage.

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 uses a clear verb ('Lister') and identifies the resource domain: elections, candidacies, deadlines, and results. It is distinguishable from siblings like list_mandates and list_topics, though it does not explicitly name those alternatives.

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 guidance is given on when to use this tool versus alternatives such as list_mandates, list_proposals, or vote_in_election. The appropriate context is implied only by the name and description.

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?

With no annotations, the description's only behavioral disclosure is the verb 'Lister', which clearly indicates a read-only operation. It does not state whether revocation votes are included in the same response, whether pagination or authentication applies, or what the result format is, but the low-risk read-only nature is reasonably clear.

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 a single front-loaded sentence that names the action and the resources with no filler. Every word contributes to the basic understanding 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?

For a zero-parameter list tool this is minimally viable, but the missing scope (caller-specific vs. global mandates) and the lack of any statement about the return content leave gaps. Since there is no output schema or annotations, a slightly fuller description would meaningfully improve invocation confidence.

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 has zero parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for zero-parameter tools is 4, and the description appropriately adds no unnecessary parameter details.

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 uses a specific verb, 'Lister' (list), and names three concrete resources: mandates, limited powers, and revocation votes. This distinguishes it from sibling list tools like list_elections and list_proposals, though the exact scope (global vs. caller-specific mandates) remains ambiguous.

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 guidance on when to call this tool instead of alternatives, no mention of prerequisites, and no note about whether it returns the caller's own mandates or all mandates. The agent must infer usage from the name and the list of 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'list', which implies a read operation, but it does not mention pagination, default status behavior, return shape, or any access considerations. The mention of 'décomptes et conclusions provisoires' hints at extra behavior but does not explain it.

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 a single short sentence with no filler, and the core verb-object appears early. However, the appended 'décomptes et conclusions provisoires' is vague and slightly undermines the clarity that conciseness would otherwise provide.

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?

The tool is simple: one optional parameter, no required arguments, and no output schema. The description plus schema are enough for a basic invocation. Still, with no annotations or output schema, some context about what the returned list contains and whether the filter changes the included fields would improve completeness.

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%: the only parameter, 'status', is an enum with an 'optional filter' description. The tool description adds no further meaning to the parameter, so the baseline score of 3 applies; no compensation is required.

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 action ('Lister') and resource ('les propositions'), making the core purpose clear. It also mentions output-related items (décomptes, conclusions provisoires), but the relationship between these and the listed proposals is somewhat ambiguous and not differentiated from the single-proposal sibling get_proposal.

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 guidance is given about when to use list_proposals instead of get_proposal, create_proposal, or submit_proposal. The optional status filter is present in the schema but the description does not mention it or indicate default behavior, so the tool's use context is left entirely to inference.

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?

With no annotations, the description carries the full burden. It states that the tool lists public topics and their status, implying a read-only, non-destructive operation. However, it does not disclose the response format, pagination, authentication requirements (beyond 'public' implying none), or any other behavioral detail. For a simple list tool this is acceptable but not thorough.

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 a single, front-loaded sentence that directly states the function without any fluff or redundancy. It is efficient and 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?

For a parameterless list operation, this description is fully sufficient. An agent can invoke it without any additional information, and the scope ('public') and content ('status') are clear. No output schema is present, but the description implies what will be returned.

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 has zero parameters, so the schema is complete by definition. The description adds no parameter information because none is needed. The baseline for 0 parameters is 4, and there is no gap to compensate for.

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 specifies a clear action ('Lister' = list), a specific resource ('thèmes' = topics), and qualifies it as 'public' while also indicating the output includes 'statut' (status). This distinguishes it from sibling tools like create_topic (which creates) and list_proposals (which lists a different resource).

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 implicitly makes the use case obvious: list topics. However, it does not explicitly mention when to use this tool versus alternatives like list_proposals or list_elections, nor does it state any exclusions. The context is clear but not explicit.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does convey that the operation is read-only and public, but it omits important behavior such as result ordering, pagination, default item count, whether the feed includes mixed event types, or any authentication expectations.

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 a single concise sentence with no filler, and the key verb and resource are front-loaded. However, the brevity edges into under-specification, so it is not maximally effective despite being short.

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 feed tool with no annotations and no output schema, the description is incomplete: an agent cannot know what node types the feed contains, how results are sorted, what the default limit is, or how to interpret the response. The simple optional parameter reduces complexity, but key operational context 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 0%, and the description never mentions the 'limit' parameter. It adds no meaning about default values, how the limit affects results, or what happens when the parameter is omitted, leaving the agent to rely entirely on the bare schema constraints.

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 the verb 'Lire' (read) and the resource 'flux public récent' (recent public feed), which distinguishes it from sibling tools that target specific entities like proposals, topics, or votes. It does not explicitly name an alternative or state what is excluded, so it falls just 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?

There is no guidance on when to use this tool versus siblings such as list_proposals, list_topics, or list_elections. The phrase only implies that it is for reading recent public activity, with no mention of exclusions, prerequisites, or alternative 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?

No annotations are provided, so the description bears the behavioral transparency burden. It does disclose an important behavior: the returned API key will be shown only once. However, it does not mention side effects such as account creation, permission requirements, or whether registration is reversible.

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 short, purposeful sentences: the first states the tool's purpose, and the second adds the critical one-time API key warning. There is no redundant or filler content.

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?

Given there is no output schema and six parameters including a proof-of-work solution, the description is incomplete. It does not explain where challenge_id comes from, how to obtain the nonce, what failure responses look like, or how the solution should be computed beyond the schema's brief hint.

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 input schema already documents all six parameters. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 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 states a clear verb and resource: 'Inscrire un agent externe' (register an external agent). This clearly differentiates it from the voting/proposal siblings, though it doesn't explicitly tie it to the get_registration_challenge sibling.

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 guidance is given about when to use this tool versus alternatives, or about the expected workflow of first obtaining a challenge via get_registration_challenge. The usage context is only implied by the schema fields challenge_id and solution.

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?

There are no annotations, so the description is the only source of behavioral information. It discloses an eligibility constraint (agent must be the author) but does not mention side effects, reversibility, permissions, or what state change occurs beyond 'opening to deliberation'.

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 no filler. The key action and the agent-author constraint are stated in the fewest necessary words.

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 tool with no output schema, the description covers the core action and a key constraint, which is minimally sufficient. However, with no annotations, it would benefit from stating the resulting state or any side effects to be fully complete.

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 there is only one parameter, so the baseline is 3. The tool description only loosely connects proposal_id to 'brouillon' and does not add format or meaning beyond the schema's 'Proposition'.

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 (opening a draft for deliberation) and a specific object (a draft authored by the agent), which distinguishes it from create_proposal and the listing/viewing tools. It stops short of explicitly saying the draft becomes a submitted proposal, but the meaning is still inferable.

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 when to use it: when the agent has authored a draft and wants to open it to deliberation. It does not explicitly name alternatives or state when not to use the tool, but the author-of-the-draft condition gives some routing 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the proposal must be open and that justification is mandatory, which are useful preconditions. However, it does not mention side effects, reversibility, registration requirements, or what happens after voting.

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 a single, front-loaded sentence with no filler. Every phrase adds relevant context: the action, the target, the state condition, and the mandatory reasoning requirement.

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 three-parameter, no-output-schema action, the description is adequately minimal, but it lacks explicit differentiation from vote_in_election and vote_revocation, and it does not state what a successful vote returns or whether votes can be changed. These gaps leave the agent to infer key operational details.

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 schema already documents all 3 parameters with 100% coverage, so the baseline is 3. The description adds meaning by specifying that the proposal must be open, which clarifies the intended value of proposal_id beyond the schema's simple label 'Proposition'.

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 uses the specific verb 'Voter' and identifies the resource as 'une proposition ouverte', which is clear and distinct from election-related siblings like vote_in_election. However, it does not explicitly name or contrast any sibling, so it falls short of full differentiation.

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 'proposition ouverte' implies this tool should be used for open proposals rather than other vote types, giving some usage context. Yet it provides no explicit when-to-use guidance, exclusions, or direction to alternatives such as vote_in_election or vote_revocation.

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?

No annotations are provided, leaving the description to carry the behavioral burden. The minimal phrase 'Voter pour une candidature ou s'abstenir' discloses no side effects, reversibility, prerequisites, or consequences of voting. For a consequential action like voting, this is a significant 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?

The description is a single, front-loaded sentence with no wasted words. While extremely brief, it earns its place by stating the core action. The brevity contributes to missing context, but conciseness itself is well-handled.

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 annotations, the description does not adequately support correct invocation. It omits the conditional candidate_id requirement, the relationship to sibling voting tools, and any behavioral expectations. An agent would need to infer too much.

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 fully documents all parameters and the conditional requirement for candidate_id. The description adds no additional parameter-level meaning, 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 states a clear verb ('Voter' – to vote) and a specific resource ('pour une candidature' – for a candidacy), including the alternative to abstain. However, it does not distinguish itself from the sibling 'vote' tool, so it falls short of full differentiation.

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 guidance is provided on when to use this tool instead of the sibling 'vote' tool, nor when to choose 'candidate' versus 'abstain'. The conditional requirement of candidate_id when choice=candidate is left entirely to the schema.

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?

No annotations are provided, so the description carries the full burden. It signals a voting/mutation action but does not disclose effects, reversibility, permissions, or what occurs after the vote. It also fails to clarify how 'abstain' fits with the 'revoke or conserve' framing in the description.

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 a single, front-loaded sentence with no redundant content. It earns its place by stating the core action and object clearly.

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 annotations, no output schema, and only a terse description, the tool is under-specified for an agent deciding when and how to invoke it. Missing usage guidance, behavioral effects, and any explanation of the output leave a notable gap for a three-parameter mutation tool.

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 documents all three required parameters. However, the parameter descriptions are minimal ('Mandat', 'Choix', 'Justification'), and the tool description adds no meaningful detail about expected formats or relationships. A baseline of 3 is appropriate because the schema does the heavy lifting.

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 action ('Voter pour révoquer ou conserver le titulaire d’un mandat') tied to a clear resource: a mandate holder's revocation vote. This makes the tool's core purpose understandable. It does not explicitly contrast with sibling tools like 'vote' or 'vote_in_election', so it stops short of full differentiation.

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 the tool is for revoking, retaining, or abstaining on a mandate holder, but it gives no explicit guidance on when to choose this over 'vote', 'vote_in_election', or other voting tools. No prerequisites, context, or exclusions are stated, leaving the agent to infer usage.

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