Skip to main content
Glama

teuton-mcp

Your AI agent checks your students' machines with Teuton, and tells you who did what. Tests written from a practice, checked, run for the class after your yes, results explained per student, grades ready for Moodle, and a teuton-panel driven from the chat.

Node.js 20+ MCP server Teuton 3.x Status: in development License: MIT

teuton-mcp is an MCP server for Teuton, the infrastructure test tool for system administration teachers: an AI agent writes a test from your practice (its targets, the commands that check them, their weights), checks it, runs it against your students' machines once you say yes, reads each student's results (which targets passed, which failed and why), and hands the grades to Moodle through the moodle-teacher extension. With a teuton-panel running in your classroom, it reads the class's results and starts runs there too. Your students' passwords never reach the AI. It's in development and not on npm yet.

โœจ Why teuton-mcp

  • ๐Ÿงช Tests from your practice. Targets, commands and expectations in Teuton's language, checked before they run.

  • โœ‹ Nothing runs without your yes. Running a test executes it on your computer and on your students' machines: the server asks you first, every time.

  • ๐Ÿ” Passwords stay out. The machines' credentials in config.yaml are never shown to the AI.

  • ๐Ÿ“‹ Results you can act on. Each student's grade and every target with what it expected and what it got.

  • ๐ŸŽ“ Grades to Moodle. Teuton's moodle.csv, ready for moodle-teacher's grade import.

  • ๐Ÿ–ฅ๏ธ Your teuton-panel too. The class in session: its results, runs, students and grades.

Related MCP server: mcp-moodle-teacher

๐Ÿงฐ What's inside (planned)

Area

For example

๐Ÿงช Tests

new_test, check_test, test_readme, list_cases

โ–ถ๏ธ Running

run_test (asks first), read_results, grades_csv

๐Ÿ–ฅ๏ธ teuton-panel

panel_status, panel_results, panel_start_run, panel_grades_csv

๐Ÿ”Œ For agents

The teuton extension in agent-extensions, with its skills and capabilities

๐Ÿ› ๏ธ Developing

The plan is in .minispec/features/teuton-tools.md and the main decisions in ADR-005 and ADR-006; CLAUDE.md lists every command. npm run build, npm test and npm run check before every commit. Releases are published to npm by the owner.

Made with ๐Ÿ’– by Falken's Lab Team

Available Tools

1 tool
server_infoServer infoA
Read-only

Show this server's name, version and data folder, and, for a server that needs programs installed apart, whether they're there. Contains no secrets.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
nameYes
nodeYes
dataDirYesWhere it keeps its state and caches
versionYes
requirementsNo

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful disclosure โ€” "Contains no secrets" โ€” signaling the output is safe to surface, plus the conditional behavior of reporting whether separate programs are installed.

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

Conciseness4/5

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

A single sentence, front-loaded with the primary payload (name, version, data folder) and ending with the conditional check. The clause about separately-installed programs is slightly wordy but earns its place by describing a non-obvious behavior.

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?

For a no-param, read-only tool with an output schema documenting the return shape and annotations covering safety, the description supplies everything an agent needs: what it returns, the conditional program check, and the reassurance that no secrets are exposed.

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 no parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The enumerated output fields are not parameters and belong to the output schema.

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?

States a specific verb ("Show") and enumerates exactly what is retrieved: server name, version, data folder, plus whether separately-installed programs are present. An agent knows precisely what this tool returns without opening the schema.

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

Usage Guidelines3/5

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

There is no explicit when-to-use statement, no prerequisites, and no alternatives named (there are no siblings). For a zero-parameter informational tool the intended use is implied and obvious, so this is adequate but not enriched.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.0.0
    • First observedserver_info

TDQS

A4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of confusion or misselection. Any agent asking for server metadata has exactly one target.

Naming Consistency4/5

The single name 'server_info' is a clean noun-based identifier, but with only one tool there is no pattern to verify consistency against. It reads predictably and would fit a consistent resource_noun convention.

Tool Count2/5

A single informational tool is very thin for an MCP server surface; there is essentially no workflow to support. It earns its place as a diagnostic, but one tool cannot be called well-scoped for a server identity like teuton-mcp.

Completeness3/5

For the narrow stated purpose of reporting name, version, data folder, and dependency presence, the tool is self-contained and complete. However, the surface offers no other operations, so any broader domain implied by the server name goes entirely uncovered.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to sign into a real Moodle LMS and handle the student workflow end to end: browsing courses, schedules, forums and grades, converting assignments and attachments into markdown, and uploading and submitting work as drafts or finalized submissions. Ships as a single static binary with write actions confirmed by the user and quiz-taking deliberately excluded.
    22
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables teachers, through AI assistants, to view courses, assignments, and student submissions, download submission files, and save grades with feedback after explicit confirmation via the Moodle REST API.
    7
    97 npm
    MIT