begin_mytu_login

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

Annotations already indicate openWorldHint (external side effects) and non-readOnly, non-idempotent. The description adds valuable behavioral context: it mentions that the user must complete password/MFA in the browser (interactive step), and that the tool returns nothing itself—the agent must later poll get_mytu_login_status. It also provides the account-matching constraint, which is not in the annotations. This goes beyond the structured metadata.

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 two sentences with no filler. The first sentence front-loads the purpose and scope, the second provides the follow-up action and a key prerequisite. Every clause adds information; no redundancy with annotations or schema.

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 login-initiating tool with no parameters and no output schema, the description covers the essential flow: what to do (open sign-in, complete MFA), what to do next (poll status), and a constraint (match Brightspace). It might benefit from clarifying what 'normal' vs 'protected' means, but given the sibling tools and the mention of get_mytu_login_status, it is sufficiently complete for an agent to proceed correctly.

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, so schema coverage is trivially 100%. The baseline for 0-param tools is 4, and the description doesn't need to elaborate on parameters. It correctly omits any parameter details, making this adequate.

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 opens the 'normal My TU Delft student sign-in' and specifies the purpose as obtaining 'official OSIRIS results.' It distinguishes itself from sibling begin_* tools by naming the specific system (My TU Delft) and the result type (OSIRIS), and by referencing a 'separate protected login' that must match Brightspace, leaving no ambiguity about what this tool does.

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 provides a clear sequence: open the sign-in, complete password/MFA in that browser, then poll get_mytu_login_status. It also adds a precondition (the protected login must match your verified Brightspace account). While it doesn't explicitly contrast with alternatives like begin_login or begin_mail_login, the specific reference to My TU Delft and OSIRIS makes the intended scenario clear, and the polling guidance is actionable.

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