Generates question banks from user-authored definitions and outputs them in GIFT or Moodle XML so the moodle-teacher extension can import the reviewed, filtered questions into a Moodle question bank. Supports true/false, multiple choice, short answer, matching and ordering questions, with per-concept and per-type review and the ability to exclude unwanted questions before import.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@asker-mcp draft a definitions file from my cell biology notes, then generate GIFT questions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your AI agent turns your definitions into a bank of questions with Asker. A definitions file drafted from your notes and checked, questions generated in GIFT or Moodle XML, and reviewed with you before they reach Moodle.
asker-mcp is an MCP server for Asker, which generates many questions (true/false, multiple choice, short answer, matching, ordering) from a file of definitions: a concept's names, its definition and its tables. An AI agent drafts that file from your notes in Asker's language, checks it, runs Asker on it, and goes through the questions with you so the bad ones are left out before the moodle-teacher extension imports the rest into your question bank. The questions come from your own definitions, the same every time. It's in development and not on npm yet.
📝 Your definitions, your questions. Every question traces back to a definition you wrote or approved.
✅ Checked first. An input with a mistake is reported with its line, and nothing is generated.
🔎 Reviewed with you. The questions by concept and type, and a copy without the ones you leave out.
🎓 Ready for Moodle. GIFT or Moodle XML, for moodle-teacher's question import.
🔁 Reusable. Your input files stay yours, to generate again next year.
Related MCP server: Moodle Study MCP
Area | For example |
📝 Inputs |
|
❓ Questions |
|
🔌 For agents | The |
The plan is in .minispec/features/asker-tools.md and the main decision in ADR-005; 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
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| node | Yes | |
| dataDir | Yes | Where it keeps its state and caches |
| version | Yes | |
| requirements | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.0server_infoScored across 1 tool
There is only a single tool, so there is no possibility of confusing it with another action or resource. Its purpose (reporting server metadata) is unambiguous.
Only one name exists, so no inconsistency is possible, but 'server_info' is a noun-style identifier rather than a verb_noun pattern, making it hard to call fully predictable.
A one-tool surface is extremely thin and essentially trivial; an agent gains almost no capability from this server beyond introspection. This is the 'too few (1)' end of the scale.
Given the narrowly stated purpose of reporting server name, version, data folder, and program-installation status, the single tool bundles all of that information. Minor gap: no separate check for individual dependencies or health beyond what one aggregate call returns.
Turn any recording or document into notes, flashcards and quizzes your agent can read and act on
Flashcards, multiple-choice quizzes, mind maps and spaced-repetition reviews from your study notes.
Turn text, files, URLs, or photos into Anki flashcard decks from your AI assistant.
Build study flashcards and exam-prep decks from your AI chat, all stored locally.