get_mail_login_status

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

The annotations already establish a safe, read-only, idempotent profile, so the bar for additional disclosure is lower, as per the rubric. The description adds a meaningful behavioral trait beyond the annotations: 'Mail access lasts only for this MCP process,' which tells the agent that the login state is non-persistent and tied to the process lifetime. 'Read' is fully consistent with readOnlyHint=true, so there is no contradiction.

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, both earning their place: the first declares the core action and scope, the second adds a critical access-lifetime caveat. The information is front-loaded with no redundancy or filler. This is a model of concise definition writing.

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 parameterless, read-only status check with a full annotation safety profile (readOnly, openWorld, idempotent), the description covers purpose, scope, and a key behavioral constraint in two sentences. No output schema exists, so the only real gap is the shape of the returned status value, but that omission is minor for such a trivial status-check tool.

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 tool has zero parameters and 100% schema description coverage, so the baseline of 4 applies. The description's mention of 'this process's' clarifies which implicit state the tool reads (the current MCP process's mail login), which is the only meaningful semantic context for a parameterless call. There is no parametric burden for the description to carry.

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 ('Read') and a well-scoped resource ('this process's university email login progress'), which makes the tool's function immediately clear. The phrase 'this process's' and 'university email' implicitly differentiate it from generic sibling status tools like get_login_status and from mutation tools like begin_mail_login. However, it never explicitly names a sibling alternative or states what it is not, so the differentiation is implicit rather than stated.

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 implies the usage context: an agent would call this to check the progress of the university email login flow, and the 'lasts only for this MCP process' warning signals that status is transient. But it does not explicitly state when to prefer this over check_mail_auth or get_login_status, nor does it mention prerequisites (e.g., that begin_mail_login must be called first) or exclusions. The guidance is implied, not made explicit.

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