Attest to Values Floor

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful constraint that the floor must already be 'loaded' and that the attestation represents agent agreement, but it says nothing about what happens on a floor_version mismatch, whether the attestation is persisted, or whether extensions alter the commitment.

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 well-formed sentence with the action front-loaded and zero filler; it is appropriately short for a two-parameter tool. It stops just short of packing in the prerequisite information that would make the brevity fully effective.

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?

This is a governance-commitment tool with no output schema, so the description is the only place the agent can learn what the attestation actually produces and what it commits to. It omits the prerequisite relationship to load_values_floor, the consequence of attesting, and whether extensions broaden the commitment — gaps that matter for a values-floor attestation.

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 floor_version and extensions are already documented in the schema and this is the baseline case. The description adds no extra semantics such as whether floor_version must match the currently loaded floor or what a valid extensions string references.

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?

Names a specific verb ('Attest') and resource ('Values Floor'), and the object clause ('that your agent agrees to abide by') makes the commitment semantics clear rather than tautological. It is distinguishable from load_values_floor in principle, but it never explicitly contrasts the two, so an agent must infer the division of labour from the names alone.

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 when-to-use guidance, no sequencing hint beyond the adjective 'loaded', and no named alternative. With siblings like load_values_floor, sign_charter, and create_disclosure in the same governance family, the description should state whether the floor must be loaded first and whether attestation is required before other calls.

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