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

With annotations already declaring readOnlyHint=false, idempotentHint=false, and destructiveHint=false, the description adds useful behavior beyond the safety profile: it returns a token and user object, mentions new-account credits, and explains how to pass the token in later calls. It does not cover failure modes, OTP expiry, or token lifetime, but it is substantially more informative than the annotations alone.

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 definition is front-loaded with the step and purpose, then gives return shape and token usage in a compact single-sentence structure. The free-credits/visuals parenthetical is slightly tangential but still relevant onboarding context, so it is efficient without being maximally tight.

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 simple two-parameter authentication step with no output schema, the description supplies the key missing context: the tool's place in the login flow, the return shape, and how to use the token afterward. It could be more complete by mentioning failure behavior or token expiry, but it is sufficient for correct invocation.

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 both `email` and `otp` are already documented in the input schema. The description reinforces that the OTP is a 6-digit login OTP sent to `email`, but it adds little parameter-level detail beyond what the schema already provides, fitting the baseline of 3.

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 states a specific verb and resource: it verifies a 6-digit Login OTP sent to `email` as Step 2 of Agent & Human Login. It also names the return shape (`{ token: 'utok_...', user }`), which makes the tool's role unambiguous against siblings like auth_request_otp and auth_login.

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 clearly places the tool as 'Step 2' of the login flow, implying it should be used after requesting an OTP. It also explains how to use the returned token in subsequent MCP calls, though it does not explicitly name auth_request_otp as the prerequisite or exclude other login alternatives.

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