Loading ToolBench
Learn Linux by fixing it: labs, journals, theory questions and your progress. Provides documentation search, lab catalogue, quizzes, and learner progress tracking via MCP protocol.
Norboten MCP server has 10 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_docs, list_labs, get_lab, quiz_me). Descriptions are substantive (100-200 chars typical), explaining WHAT and WHEN. However, parameter descriptions lack detail on constraints, formats, and valid ranges. Output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling is absent from descriptions. All tools are READ_ONLY, reducing risk but also limiting composition patterns. No tool annotations (readOnlyHint) present despite being marked READ_ONLY in metadata.
One lab: its briefing, objectives, what each check verifies, and the first two hint levels with their reading. Never the solution, never hints 3 and 4 — those are for the learner to ask for in the TUI.
The top learners by pass rate and by total attempts, with optional filtering by topic.
Every lab, or those of one track (rhcsa, linux, bash, python, ansible, docker, terraform, automation, claude, intro) or one topic slug.
The topics labs, questions and ratings are filed under.
The labs being run right now, by whom, and how far they have got.
Every attempt the learner has made: when, which lab, which checks passed, and the machine state before and after.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting) for downstream tool chaining or data extraction. E.g., list_labs returns what? Array of objects with which fields?
Parameter descriptions lack constraint details. E.g., 'limit' in search_docs says '1-10' in description but no min/max schema constraints. 'difficulty' in quiz_me has no valid range documented. 'track' in list_labs lists valid values in description but not as enum.
No tool annotations present. All tools are READ_ONLY but lack readOnlyHint annotation in schema. quiz_me has side effects (user state tracking) but no annotation. Prevents LLM from optimizing execution strategy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
The learner's progress: labs attempted, passed, and in progress, with pass rates by topic.
The learner's rating on a topic: how many they have passed, how many they have attempted, and their percentile.
One theory question on a topic (or a lab id), asked of the user directly: the client shows it, the user answers, and the result says whether it was right and why. A client that cannot ask its user gets the question back, and answer is requested via elicitation.
Search Norboten's documentation, journals (without their walkthroughs), lab briefings and question explanations. BM25 over exact terms: ask with the words you expect in the text.
Error handling not documented. No guidance on what errors tools return, when they are retryable, or what the LLM should do next. E.g., what if lab_id is invalid in get_lab? What if user is not authenticated in my_progress?
Parameter naming inconsistency. 'topic' used as both filter (list_labs, leaderboard) and primary input (quiz_me, my_rating). 'lab_id' vs 'topic' in quiz_me creates ambiguity, can both be passed? Are they mutually exclusive?