ZHAW Moodle MCP Server

Overview Schema Source Related Servers Discussions Admin

moodle_search

Read-onlyIdempotent

Search Moodle by name across courses, sections, materials, assignments, quizzes, and files. Tolerates typos and umlauts, with optional filters for course and result type.

Instructions

Search Moodle by name: courses, sections, materials (files, folders, links, pages), assignments, quizzes and files inside folders. Case- and umlaut-insensitive, tolerant to small typos; all words must match (e.g. "OR ZGB", "Übung 3", "Semesterprogramm").

    Args:
        query: words to look for
        course_id: restrict to one course
        kinds: restrict result kinds: course, section, module (activities/materials), file (in folders)
        source: "index" = local index of names (fast; current courses are refreshed automatically),
            "moodle" = Moodle's full-text search (also finds words inside text areas),
            "auto" = index first, Moodle full-text search if nothing matches
        limit: maximum number of hits
        refresh: re-read the courses from Moodle before searching

Input Schema

TableJSON Schema

Name	Required	Default
`kinds`	No
`limit`	No
`query`	Yes
`source`	No	auto
`refresh`	No
`course_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hits`	Yes
`note`	No
`query`	Yes
`source`	Yes
`indexed_courses`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 16, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already mark the operation read-only, idempotent, and open-world. The description adds meaningful behavioral context: case/umlaut-insensitivity, typo tolerance, the all-words-must-match rule, refresh behavior, and the fallback logic of 'auto'. This goes beyond the annotation-provided safety profile.

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?

The description is compact and front-loaded: purpose first, then matching behavior, then a clean Args list. Every sentence earns its place and no irrelevant detail is included.

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

Completeness5/5

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

Given an output schema, read-only annotations, and six parameters, the description covers matching semantics, source selection, scoping by course and kind, limit, and refresh. It provides everything an agent needs to invoke the tool correctly without requiring further inference.

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

Parameters5/5

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

With schema description coverage at 0%, the description fully compensates by explaining all six parameters: query, course_id, kinds, source, limit, and refresh. Each parameter gets a concise, meaningful explanation that the bare schema does not provide.

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

Purpose5/5

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

Description states a specific verb ('Search') and resource ('Moodle by name') and enumerates the exact kinds of entities covered, plus the special case of files inside folders. This is distinct from sibling list/get tools and conveys exactly what the tool does.

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?

Provides clear context for when to use the tool and, importantly, explains the three source modes ('index', 'moodle', 'auto') and when each is appropriate. It does not explicitly name sibling alternatives or exclusion conditions, but the source-selection guidance is strong enough to guide an agent.

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

Deploy Server