Loading ToolBench
MCP server for University of Tuebingen study systems integration, providing tools for course discovery, schedule management, task tracking, mail access, and course registration across Alma, ILIAS, and Moodle portals.
This MCP server defines 26 tools with generally clear naming and descriptions. Most tools follow verb_noun convention (get_, search_, prepare_, confirm_). Descriptions are substantive (averaging ~120 chars) and include context on when to use each tool. However, significant gaps exist: (1) Output schemas are NOT documented in the provided source, we can see input schemas but no return type definitions for any tool; (2) Error handling guidance is absent, tools do not indicate recovery steps or error classification; (3) Parameter descriptions vary in quality, some lack type hints or constraints; (4) Security considerations around token/credential handling are not visible in the schema; (5) The 'prepare_*' + 'confirm_critical_action' pattern is innovative for reversible operations but lacks explicit idempotency and multi-round-trip documentation. Composition is strong, tools chain well (prepare → confirm pattern), though the two-step process adds cognitive load. Overall: solid foundational work, but lacks the production-grade completeness (documented outputs, error recovery, idempotency guarantees) expected of A-tier toolkits.
Use only from the confirmation widget after the user presses Proceed. It executes the prepared action exactly once.
Use this when the user already has an item id from search and wants the full text for that Alma or ILIAS result.
Use this when the user wants one course page that combines Alma details with signup status across Alma, ILIAS, and Moodle.
Use this before module discovery when you need the valid Alma filter values for degrees, subjects, faculties, languages, or element types.
Use this when the user already has an Alma detail URL and wants structured detail sections, including module/study-program assignments when Alma exposes them.
Use this when the user asks about grades, passed exams, credits, or current Alma study progress.
Output schemas not documented. While all 26 tools have input schemas with types and descriptions, no return type definitions or output field descriptions are visible. Tools like search_courses, get_mail_inbox, and get_study_snapshot must return structured data, but downstream tool callers cannot know what fields are available for chaining.
Generic tool names 'search' and 'fetch' violate clarity principles. These names do not convey domain (search what? fetch which resource?). LLMs will struggle to distinguish when to use search vs search_courses vs search_learning_spaces. Additionally, 'fetch' is vague, does it mean retrieve full text, download, or get metadata?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Use this when the user asks about open ILIAS tasks, due items, or assignment deadlines.
Use this when the user wants Alma document jobs, transcript options, output-request groups, or the current study-service PDF.
Use this when the user asks which ILIAS courses, groups, or learning spaces they currently belong to.
Use this when the user wants to triage inbox messages, filter by sender, search mailbox text, or look at unread mail.
Use this when the user wants the full plaintext body and headers for a specific mail UID from the inbox response.
Use this when the user asks about mensa menus, cafeteria food, lunch options, or vegan and vegetarian meals in Tübingen.
Use this when the user wants the semester grid, recommended plan, or current module layout from Alma's study planner.
Use this when the user asks for an overall status update or combines multiple questions about upcoming lectures, open tasks, grades, and learning spaces.
Use this when the user asks about next lectures, meetings, classes, or calendar items from Alma.
Use this when the user wants the contents, forum topics, and exercise assignments for a specific ILIAS target URL or goto reference.
Use this when the user specifically wants Alma study-service document jobs or certificate options in the widget.
Use this when the user wants to register for an Alma course. This only renders a confirmation UI; it never registers until the user presses Proceed.
Use this when the user wants to add an ILIAS item to favorites. This only renders a confirmation UI until the user presses Proceed.
Use this when the user wants to join an ILIAS course waitlist. This only renders a confirmation UI until the user presses Proceed.
Use this when the user wants to self-enrol in a Moodle course. This only renders a confirmation UI until the user presses Proceed.
Use this when the user wants to search Alma and ILIAS items by topic, course name, or document label.
Use this when the user wants live Alma course offerings for a term, such as current or upcoming lectures and searchable course detail URLs.
Use this when the user wants public module descriptions filtered by degree, subject, faculty, language, or element type.
Use this when the user wants to search authenticated ILIAS content beyond current memberships, optionally with advanced filters like content type or creation date.
Use this when the user wants a compact overview of upcoming events, documents, exams, and ILIAS entry points.
No error handling or recovery guidance. Tools do not describe what errors they may return, whether they are retryable, or what the LLM should do next. For example, 'confirm_critical_action' could fail with 'invalid token', 'action already executed', or 'session expired', but no guidance is provided on whether to retry, ask the user, or escalate.
No idempotency or confirmation guarantees documented. The prepare_* + confirm_critical_action pattern is elegant for preventing accidental actions, but lacks formal specification of: (1) whether confirm can be called multiple times with the same token (idempotency), (2) how long tokens remain valid, (3) what happens if a session expires mid-flow.
Several tools with complex filtering have unclear parameter relationships. For example, search_learning_spaces accepts createdMode and createdDate but lacks documentation on whether both are required together, what modes are valid, or what happens if createdEnabled=false but createdDate is provided.
No pagination guidance for large result sets. Tools like search_courses accept maxResults but do not document total count, next_cursor, or how to fetch the next page. Agents iterating over all results have no standard mechanism.
Tools accepting optional parameters with unclear defaults. For example, search_learning_spaces has page, searchMode, and contentType but does not state default page=1, what searchMode values are valid, or what contentType values mean.