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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description usefully reinforces this with "opens nothing by itself" and explains that the actual mutation must be done through cotlet_browser_* tools that are not this one. It also discloses the design rationale (API/MCP coverage gap, dated check), which is context no annotation field carries. It stops short of stating prerequisites such as whether a browser session must already be open or authenticated.

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?

Three sentences, front-loaded with what it does, followed by the handoff to cotlet_browser_* and a justified aside about the official API. Every sentence carries information, though the API/coverage sentence is a slight detour relative to the core call-and-handoff flow.

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?

No output schema exists, and the description does explain the return shape (step-by-step screens, buttons, fields) plus the required follow-up tooling, which is what an agent needs to chain correctly. The remaining gap is the absence of any statement about how the target account, group, and users are identified when the tool takes no parameters.

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?

With zero parameters, the schema provides no guidance and the description must compensate. It never explains how the tool knows which users and which group are involved given that it accepts no arguments, leaving open whether it returns generic instructions or account-specific ones. This is a meaningful semantic hole for a tool whose stated purpose is adding specific users to a specific group.

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 names the specific verb and resource (add users to a group in LearnUpon) and then corrects the likely misreading by stating it "Returns how to do it in LearnUpon step by step (screens, buttons, fields)" rather than performing the action. The correction is clear, though the leading sentence still reads like a write action, which creates a brief ambiguity an agent could skim past.

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 an explicit two-step workflow: call this to get instructions, then execute via cotlet_browser_* in the LearnUpon Cloud Browser. It also justifies itself against an alternative (LearnUpon's REST API and reporting MCP server don't cover day-to-day admin work). It does not compare itself to sibling tools like learnupon_enroll_group_on_course or learnupon_invite_users, so an agent choosing among the learnupon_* family gets no routing help.

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