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

With no annotations provided, the description carries the full behavioral burden and does substantial work: it discloses side effects (emails a 6-digit code), session-wide statefulness (later tools run as that person), the headless-only constraint, and a security rule (do not store code/token). It stops short of covering failure/retry behavior or expiry, but the key stateful and side-effectful traits are clearly surfaced.

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?

Every sentence earns its place: purpose and constraint in line one, routing guidance in line two, and a numbered invocation sequence. The most important qualifier (last-resort, headless-only) is front-loaded, and the step numbering makes the multi-call flow easy to follow without padding.

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 an output schema exists (so return values need not be spelled out) and 100% parameter coverage, the description completes the picture with the flow states, the conditional org branch, and post-auth session behavior. The only minor gap is failure mode handling (e.g., wrong code), but nothing needed to invoke the tool correctly across its documented states is missing.

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 the parameter descriptions already explain email, code, and org_id semantics including the code_sent and need_org statuses. The description adds orchestration context (which order to pass parameters in), but per-parameter meaning is fully carried by the schema, matching the baseline-3 case for high coverage.

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?

Opens with a specific verb+resource statement: 'email + OTP bind for this MCP session (headless only).' The 'last-resort' qualifier and 'headless only' constraint make its role unmistakable, and among the sibling list (org_bind, health, version) there is no competing auth tool, so an agent can identify it immediately.

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?

Explicitly tells the agent when NOT to call it ('Do not call this as the first hop'), names the preferred alternatives (Cursor Connect, 'tsk_' header), and gives a concrete condition for when it is appropriate ('When the host has no token'). The numbered 3-step flow with the conditional need_org branch leaves no ambiguity about invocation order.

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