Opens a login window for the user to authenticate to Moodle and waits until the browser is closed, enabling an authenticated session for course data access.
利用者 PC にログイン用ウィンドウを開く。本人がログインしてブラウザを終了するまで待つ。 Mac ではウィンドウを閉じるだけではブラウザが終わらないので、⌘Q で終了するよう利用者に伝える。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, which doesn't tell the agent much about this tool. The description adds the crucial behavior: it opens a UI window on the user's machine and blocks until the person logs in and closes the browser, plus the macOS ⌘Q caveat. What's missing is timeout/failure handling and whether the login persists for later calls.
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 short sentences, front-loaded with the action, then the wait semantics, then the platform-specific instruction. Every sentence carries information the agent or user needs.
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 thin annotations, the description carries the burden well by explaining the interactive blocking flow and the user-facing instruction. It is slightly incomplete about what happens after the window closes (is the agent's session now authenticated, what if login fails).
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, so the baseline is 4 and there is nothing for the description to disambiguate. Schema coverage is 100% for an empty object.
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 and object (opens a login window on the user's PC) plus the wait condition, which clearly separates it from the sibling tools that all read Moodle data. It never names a sibling explicitly, 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?
Usage is only implied: because the tool waits for a human to log in, an agent can infer it is the interactive prerequisite before the read-oriented siblings. The description never says when to call this instead of them, nor what to do if a session already exists or the user abandons the login.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.