moodle-um

moodle_login

Opens a Chromium window for ENT/CAS sign-in, waits for identifiant, password, and MFA, then closes and saves the session so you can access Moodle without repeating login until it expires.

Instructions

Open a Chromium window so the user can sign in through ENT/CAS.

The window stays open until the user completes the ENT login (identifiant, password, MFA). It then closes automatically and the session is saved. Only needed once, or when the session has fully expired.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "moodle_login"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 12, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the important traits: a window opens, the call blocks until a human completes identifiant/password/MFA, the window self-closes, and the session is persisted. It does not cover failure or timeout behavior, whether a display environment is required, or what happens if a valid session already exists when called.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and mechanism, then lifetime behavior, then the when-to-call rule. No filler and no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool this covers the essentials an agent needs: that it is interactive, blocking, and persistent. The remaining gap is error/timeout handling, which matters for an interactive flow but is a modest omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema baseline is 4. The description usefully clarifies that credentials are entered interactively by the user rather than passed as arguments, which prevents an agent from hunting for auth parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and mechanism: opening a Chromium window and having the user sign in through ENT/CAS. An agent can distinguish this from data-fetching siblings like moodle_get_course, though the description never names a sibling (moodle_status would be the natural counterpoint) to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit usage condition: needed once, or when the session has fully expired. What is missing is the negative case — no instruction on checking session state first, and no named alternative for determining whether a login is actually required.

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