Api ebios rm operating modes likelihood retrieve

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds zero behavioral context of its own — no indication of what the returned likelihood object contains, whether auth/tenant scoping applies, or what happens for a nonexistent id. With annotations doing all the work, this sits just above the floor.

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 short but not concise in any useful sense — it is a single identifier string with no front-loaded verb-resource statement, no scope, and no actionable content. Brevity here reflects under-specification rather than efficient editing.

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 id, no output schema) and annotations cover safety, but the description still leaves the core question unanswered: what 'likelihood' is computed and returned for an operating mode. There is no mention of the domain concept (EBiOS RM operating mode likelihood, presumably derived from kill chain / elementary action likelihood), which an agent cannot infer from the name alone.

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 one required parameter, 'id', with 0% schema description coverage, so the description must carry the semantics and it does not. It never states that the id refers to an EBiOS RM operating mode, nor what form the identifier takes. Only the tool name implicitly hints the parameter is an operating mode identifier.

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 is the raw tool identifier restated verbatim, so it functions as a tautology rather than an explanation. The name does decompose into 'retrieve likelihood for EBiosity operating modes', but nothing in the description clarifies what a 'likelihood' value is or that it is scoped to a single operating mode. It does not distinguish this from sibling endpoints such as operational_scenarios_likelihood_retrieve or ebios_rm_studies_likelihood_retrieve.

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 when-to-use, when-not-to-use, or alternative routing guidance is given. An agent facing four similarly named 'likelihood_retrieve' endpoints has no textual basis for choosing this one. The description offers nothing beyond the identifier string.

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