start_login

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

Adds real context beyond the annotations: the call returns immediately rather than blocking, the person types credentials only in that window and the MCP never sees them, and nothing is changed server-side on the Campus. That last point usefully reinterprets readOnlyHint=false (non-read-only only in the sense that it opens local UI). It does not say what happens if the window is closed, fails to open, or if a browser is missing.

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?

Four short sentences, each carrying distinct load: what opens, the credential boundary, the required follow-up, and the no-server-effect scope. The action and its scope are front-loaded with no filler.

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?

With no parameters, no output schema, and annotations covering safety and open-world behavior, the description supplies the pieces an agent needs: non-blocking return, credential handling, and the required session_status follow-up. Only failure modes (browser not installed, window dismissed) are left unaddressed.

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 takes zero parameters and the description correctly says nothing about inputs, which is appropriate. No meaning is missing because there is nothing to parameterize.

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?

States a concrete verb and resource: it opens a browser window on the person's computer at the Campus login page to start or renew a session, and returns immediately. It also explicitly bounds the tool's effect with "No hace nada en el Campus", which separates it from the session/state tools in the sibling list.

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?

Gives the trigger (to start or renew the session) and an explicit follow-up step: "Después hay que consultar session_status." It also clarifies the human-in-the-loop credential flow, which is the reason to pick this over any direct auth tool. It does not mention prerequisites such as install_browser when no browser is present, which is the one remaining routing gap.

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