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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is known. The description adds genuinely new context about the temporary-site/claimToken restriction, which annotations do not convey. However, it never states the destructive consequence (disabling protection makes the site publicly readable) or how the optional fields interact, which is the kind of behavior an agent most needs here.

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, front-loaded with the primary action and followed immediately by the exception. No filler, no restatement of the title.

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 destructive, five-parameter mutation with no output schema and no schema-level parameter documentation, the description leaves too much undefined: the meaning of accessDurationSeconds, the behavior when disabling protection, and the result of the call. The temporary-site rule is the only substantive addition.

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% across five parameters, so the description carries the full burden. It explains claimToken's purpose and implies slug/enabled/password, but accessDurationSeconds is never mentioned and its 60–31536000 range is left entirely unexplained, and the interaction between enabled=false and a supplied password is undefined.

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 verb set (turn on, turn off, change) against a specific resource (a site's password), which is unambiguous. It does not explicitly differentiate itself from siblings, but no sibling plausibly overlaps with password management, so the risk of misselection is low.

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?

It supplies a concrete conditional rule: on a temporary site you can only change or remove an existing password, and a claimToken is required. That is actionable when-to-use context. What is missing is guidance on the enabled=false path (does it clear an existing password?) and when accessDurationSeconds applies.

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