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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the crucial hidden side effect that this call switches the connection so all subsequent tools operate inside the new project, and that a site is created alongside the project. It also states that no confirmation prompt is expected, which shapes agent behavior. It does not say what is returned (new project id/handle) or whether creation is reversible, so it stops short of full transparency.

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?

Only four sentences and no filler, with the core condition front-loaded. However the middle sentence about current-project creation is not clearly scoped to this tool and interrupts the flow between the precondition and the exclusion, costing clarity.

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 state-mutating tool that creates a project plus a site and changes the session's active scope, the description omits the return value and whether name collisions or quota limits apply. It also flags a contradictory usage path ('créer/cloner directement dans le projet/site/domaine courants'), which leaves the agent unsure whether calling this tool or staying in the current project is correct.

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 ('name') with 0% schema description coverage, and the description never mentions it — no naming rules, uniqueness constraints, or whether the name propagates to the created site/domain. With low coverage the description was expected to compensate and does not.

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?

States a specific verb+resource ('Créer un NOUVEAU projet (avec son site)') and constrains it to the case where a distinct project/site is explicitly requested. It is distinguishable from create_site_project and switch_project because it names the context-switch effect and the sibling it must not replace. The one drag is the sentence about creating directly in the current project, which reads as a general routing rule rather than this tool's job and briefly muddies what the tool itself does.

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?

Gives an explicit precondition ('uniquement si un projet/site distinct est explicitement demandé ou si aucun projet utilisable existe') and an explicit exclusion naming the alternative tool ('Ne pas l'utiliser pour modifier un site existant (switch_project)'). The extra clause about no destination specified and no confirmation is a useful operating instruction but sits in tension with the tool's create-new scope, leaving a small ambiguity an agent must resolve.

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