seerr_request_password_reset

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

The description explicitly notes 'WRITE' and that it modifies the Seerr instance, which aligns with the readOnlyHint=false annotation but adds minimal new information beyond it. It does not disclose side effects such as email delivery, authentication requirements, or error behavior.

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 very short and to the point, avoiding unnecessary verbiage. However, the 'WRITE' clause is somewhat redundant with existing annotations, slightly reducing its value.

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 ambiguous schema and lack of details about the request body, expected response, or prerequisites, the description is insufficient for reliable invocation. The relationship to sibling tool seerr_reset_password is not clarified.

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 defines a single 'body' object with no properties and no descriptions (0% coverage). The description does not explain what the body should contain, leaving the agent with no guidance on how to construct the request.

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 sends a reset password email, which is a specific action. However, it does not explicitly distinguish from sibling tool seerr_reset_password, leaving potential confusion about which to use for direct password resets.

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 like seerr_reset_password or other user password tools. It does not state prerequisites or scenarios.

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