The Education AI MCP server provides AI-powered tools for educational content creation, student assessment, and personalized learning recommendations.
Generate Lesson Plans: Create structured lesson plans with objectives, activities, assessments, and optional differentiation strategies for any subject, topic, age group, and duration.
Create Quizzes: Build quizzes with multiple question types (multiple choice, true/false, short answer, fill-in-the-blank, matching), configurable difficulty, Bloom's taxonomy alignment, and an optional answer key.
Analyze Student Progress: Input student assessment scores over time to receive performance trend analysis and progress reports against a target grade.
Recommend Learning Paths: Generate personalized learning paths based on a student's subject, proficiency level, learning style, goals, and available study hours.
Generate Assessment Rubrics: Produce detailed grading rubrics with customizable criteria, performance levels (3–5), and scoring for assignment types such as essays, presentations, projects, lab reports, and portfolios.
EU AI Act Compliance: Built-in features for risk management, transparency, bias detection, and AI content watermarking.
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., "@Education AI MCP create a 10-question quiz on photosynthesis for 8th graders"
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.
MEOK AI Labs MCP Server
MEOK AI Labs MCP Server
# Install via pip
pip install education_ai_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install education-ai-mcp --client claudeRelated MCP server: teachermall-mcp
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic →
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support
View Pricing → | Contact Sales →
This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT © CSOAI-ORG
Build something that touches users? You need compliance. MEOK ships 38 governance MCPs that drop in alongside this tool — EU AI Act, DORA, NIS2, CRA, GDPR, ISO 42001, FDA SaMD, MDR, Basel, MiFID II, MiCA, COPPA, and more.
# One-shot install of the governance pack
npx meok-setup --pack governanceFree tier: 10 calls/day per MCP. Pro tier (£79/mo): unlimited + cryptographically signed compliance attestations your auditor verifies independently.
→ Full catalogue: councilof.ai/catalogue → MEOK AI Labs: meok.ai
Tier | Price | What you get | Stripe |
Smoke test | £1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | £9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | £29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe — VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"education-ai-mcp": {
"command": "uvx",
"args": ["education-ai-mcp"]
}
}
}Or: pip install education-ai-mcp then run the education-ai-mcp command (stdio transport).
Once configured, ask your assistant, for example:
"Use generate_lesson_plan to …"
"Use create_quiz to …"
"Use analyze_student_progress to …"
Analyze student performance trends and generate progress report.
Args:
student_name: Student's name
assessments: List of dicts with keys: subject, score (0-100), date, assessment_name (optional)
target_grade: Target grade percentage
Behavior:
This tool generates structured output without modifying external systems.
Output is deterministic for identical inputs. No side effects.
Free tier: 10/day rate limit. Pro tier: unlimited.
No authentication required for basic usage.
When to use:
Use this tool when you need structured analysis or classification
of inputs against established frameworks or standards.
When NOT to use:
Not suitable for real-time production decision-making without
human review of results.
Behavioral Transparency:
- Side Effects: This tool is read-only and produces no side effects. It does not modify
any external state, databases, or files. All output is computed in-memory and returned
directly to the caller.
- Authentication: No authentication required for basic usage. Pro/Enterprise tiers
require a valid MEOK API key passed via the MEOK_API_KEY environment variable.
- Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are
included in responses (X-RateLimit-Remaining, X-RateLimit-Reset).
- Error Handling: Returns structured error objects with 'error' key on failure.
Never raises unhandled exceptions. Invalid inputs return descriptive validation errors.
- Idempotency: Fully idempotent — calling with the same inputs always produces the
same output. Safe to retry on timeout or transient failure.
- Data Privacy: No input data is stored, logged, or transmitted to external services.
All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| student_name | Yes | ||
| assessments | Yes | ||
| target_grade | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only, idempotent, no side effects, authentication requirements, rate limits (10/day free), error handling (structured errors), data privacy (no storage). Comprehensive and clear.
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?
Well-structured with clear sections, though there is minor redundancy between 'Behavior' and 'Behavioral Transparency'. Overall front-loaded and efficient for its detail level.
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?
Given 4 parameters, no annotations, and no output schema, the description is quite complete. It covers purpose, usage, parameters, and behaviors. The only gap is the lack of a success output format description, but structured output is implied.
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 'Args' section adds meaning to student_name, assessments (list of dicts with specific keys), and target_grade, despite 0% schema coverage. The api_key parameter is also mentioned in behavioral transparency, providing context beyond the 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?
The description clearly states 'Analyze student performance trends and generate progress report', specifying a concrete verb and resource. It distinguishes from sibling tools like create_quiz and generate_lesson_plan by focusing on analysis and reporting.
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?
Provides explicit 'When to use' and 'When NOT to use' sections, advising against real-time decision-making without human review. However, it does not name specific alternative tools for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a quiz with various question types aligned to Bloom's taxonomy.
Args:
topic: Quiz topic
num_questions: Number of questions (max 30)
difficulty: Difficulty level: easy, medium, hard, mixed
question_types: Types to include: multiple_choice, true_false, short_answer, fill_blank, matching
age_group: Target age group
include_answers: Include answer key
Behavior:
This tool generates structured output without modifying external systems.
Output is deterministic for identical inputs. No side effects.
Free tier: 10/day rate limit. Pro tier: unlimited.
No authentication required for basic usage.
When to use:
Use this tool when you need structured analysis or classification
of inputs against established frameworks or standards.
When NOT to use:
Not suitable for real-time production decision-making without
human review of results.
Behavioral Transparency:
- Side Effects: This tool is read-only and produces no side effects. It does not modify
any external state, databases, or files. All output is computed in-memory and returned
directly to the caller.
- Authentication: No authentication required for basic usage. Pro/Enterprise tiers
require a valid MEOK API key passed via the MEOK_API_KEY environment variable.
- Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are
included in responses (X-RateLimit-Remaining, X-RateLimit-Reset).
- Error Handling: Returns structured error objects with 'error' key on failure.
Never raises unhandled exceptions. Invalid inputs return descriptive validation errors.
- Idempotency: Fully idempotent — calling with the same inputs always produces the
same output. Safe to retry on timeout or transient failure.
- Data Privacy: No input data is stored, logged, or transmitted to external services.
All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| num_questions | No | ||
| difficulty | No | mixed | |
| question_types | No | ||
| age_group | No | 14-16 | |
| include_answers | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully covers behavioral traits: side effects (read-only, no modifications), authentication (no auth basic, API key for pro), rate limits (10/day free), error handling (structured errors), idempotency, and data privacy. This exceeds expectations.
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?
The description is well-structured with clear sections (Args, Behavior, When to use/not use, Behavioral Transparency). While slightly verbose, every section adds value, especially given the absence of annotations.
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?
Covers most aspects but lacks description of the return value format. For a quiz creation tool, specifying the output structure (e.g., JSON quiz object) would enhance completeness. No output schema is provided, so this omission is notable.
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 'Args' section adds meaning beyond the input schema by listing allowed values for difficulty and question_types, default for num_questions, etc. However, the api_key parameter is mentioned in the behavioral section but not in the Args list, slightly reducing clarity.
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?
The description clearly states 'Create a quiz with various question types aligned to Bloom's taxonomy,' which is a specific verb+resource. It distinguishes from sibling tools like analyze_student_progress or generate_lesson_plan, which have different purposes.
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?
Explicit 'When to use' and 'When NOT to use' sections provide guidance, though the 'When to use' text ('structured analysis or classification...') is somewhat generic and could be more directly tied to quiz creation. Still, it offers clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a structured lesson plan with objectives, activities, and assessment.
Args:
subject: Subject area (e.g. "Mathematics", "Science", "English")
topic: Specific topic (e.g. "Quadratic Equations", "Photosynthesis")
age_group: Student age range (e.g. "11-13", "14-16", "16-18")
duration_minutes: Lesson duration in minutes
learning_objectives: Custom objectives (auto-generated if omitted)
differentiation: Include differentiation strategies
Behavior:
This tool generates structured output without modifying external systems.
Output is deterministic for identical inputs. No side effects.
Free tier: 10/day rate limit. Pro tier: unlimited.
No authentication required for basic usage.
When to use:
Use this tool when you need structured analysis or classification
of inputs against established frameworks or standards.
When NOT to use:
Not suitable for real-time production decision-making without
human review of results.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| topic | Yes | ||
| age_group | No | 14-16 | |
| duration_minutes | No | ||
| learning_objectives | No | ||
| differentiation | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it generates structured output without modifying external systems, is deterministic, has no side effects, specifies rate limits (free 10/day, pro unlimited), and states that no authentication is required for basic usage. This is comprehensive.
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?
The description is well-structured with an intro, Args list, Behavior section, and usage guidelines. It is not overly verbose, though the 'When to use' sections could be slightly more concise. Overall, it is clear and organized.
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?
Given 7 parameters, no output schema, and no annotations, the description covers purpose, usage, and most parameters but misses the 'api_key' parameter and does not describe the output format. The 'When NOT to use' is generic. It is adequate but has gaps.
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?
Input schema has 0% description coverage, so the description must compensate. It adds examples for subject, topic, age_group, and duration_minutes, clarifies learning_objectives as optional and auto-generated, and explains differentiation. However, it omits the 'api_key' parameter entirely, leaving it undocumented. This is good but not perfect.
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?
The description clearly states it generates a structured lesson plan with objectives, activities, and assessment. The verb 'Generate' and resource 'lesson plan' are specific, and it distinguishes itself from sibling tools like analyze_student_progress, create_quiz, generate_rubric, and recommend_learning_path.
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?
The description includes explicit 'When to use' and 'When NOT to use' sections, providing clear context. However, the 'when to use' is somewhat generic and does not directly contrast with siblings, though it mentions rate limits and authentication requirements. This is still above average.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an assessment rubric with detailed criteria and descriptors.
Args:
assignment_title: Title of the assignment
criteria: Custom assessment criteria (auto-generated if omitted)
levels: Number of performance levels (3-5)
max_score: Maximum total score
assignment_type: Type: essay, presentation, project, lab_report, portfolio
Behavior:
This tool generates structured output without modifying external systems.
Output is deterministic for identical inputs. No side effects.
Free tier: 10/day rate limit. Pro tier: unlimited.
No authentication required for basic usage.
When to use:
Use this tool when you need structured analysis or classification
of inputs against established frameworks or standards.
When NOT to use:
Not suitable for real-time production decision-making without
human review of results.
Behavioral Transparency:
- Side Effects: This tool is read-only and produces no side effects. It does not modify
any external state, databases, or files. All output is computed in-memory and returned
directly to the caller.
- Authentication: No authentication required for basic usage. Pro/Enterprise tiers
require a valid MEOK API key passed via the MEOK_API_KEY environment variable.
- Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are
included in responses (X-RateLimit-Remaining, X-RateLimit-Reset).
- Error Handling: Returns structured error objects with 'error' key on failure.
Never raises unhandled exceptions. Invalid inputs return descriptive validation errors.
- Idempotency: Fully idempotent — calling with the same inputs always produces the
same output. Safe to retry on timeout or transient failure.
- Data Privacy: No input data is stored, logged, or transmitted to external services.
All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| assignment_title | Yes | ||
| criteria | No | ||
| levels | No | ||
| max_score | No | ||
| assignment_type | No | essay | |
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It extensively covers side effects (read-only, no state modification), authentication, rate limits, error handling, idempotency, and data privacy, leaving no ambiguity about safety or constraints.
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?
The description is well-organized with clear sections (Args, Behavior, When to use/not, Behavioral Transparency). However, it is somewhat verbose, with redundant statements (e.g., 'Behavior' and 'Behavioral Transparency' both mention no side effects). Still, it remains readable and front-loaded.
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?
Given no output schema and 0% schema coverage, the description covers most aspects thoroughly—purpose, usage, behavior, and constraints. However, it omits the output structure (e.g., format of the rubric) and fails to describe the api_key parameter. Overall, quite complete but with minor gaps.
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?
Schema description coverage is 0%, but the description lists parameters with brief explanations (e.g., 'criteria: Custom assessment criteria (auto-generated if omitted)'). However, the 'api_key' parameter in the schema is not mentioned in the description, and details like enum values for 'assignment_type' are only hinted via examples. Thus, partial compensation.
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?
The description begins with 'Generate an assessment rubric with detailed criteria and descriptors,' which clearly states the tool's specific verb+resource. It distinguishes itself from siblings like 'analyze_student_progress' and 'create_quiz' by focusing on rubric generation.
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?
The description includes dedicated 'When to use' and 'When NOT to use' sections, providing explicit guidance on appropriate contexts (structured analysis/classification) and exclusions (not for real-time production decision-making without human review). It also mentions rate limits for free vs pro tiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a personalized learning path based on student profile.
Args:
subject: Subject area
current_level: Current proficiency: beginner, intermediate, advanced
learning_style: Learning style: visual, auditory, kinesthetic, reading_writing
goals: Specific learning goals
available_hours_per_week: Hours available for study per week
Behavior:
This tool is read-only and stateless — it produces analysis output
without modifying any external systems, databases, or files.
Safe to call repeatedly with identical inputs (idempotent).
Free tier: 10/day rate limit. Pro tier: unlimited.
No authentication required for basic usage.
When to use:
Use this tool when you need structured analysis or classification
of inputs against established frameworks or standards.
When NOT to use:
Not suitable for real-time production decision-making without
human review of results.
Behavioral Transparency:
- Side Effects: This tool is read-only and produces no side effects. It does not modify
any external state, databases, or files. All output is computed in-memory and returned
directly to the caller.
- Authentication: No authentication required for basic usage. Pro/Enterprise tiers
require a valid MEOK API key passed via the MEOK_API_KEY environment variable.
- Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are
included in responses (X-RateLimit-Remaining, X-RateLimit-Reset).
- Error Handling: Returns structured error objects with 'error' key on failure.
Never raises unhandled exceptions. Invalid inputs return descriptive validation errors.
- Idempotency: Fully idempotent — calling with the same inputs always produces the
same output. Safe to retry on timeout or transient failure.
- Data Privacy: No input data is stored, logged, or transmitted to external services.
All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| current_level | No | intermediate | |
| learning_style | No | visual | |
| goals | No | ||
| available_hours_per_week | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description thoroughly discloses behavior: read-only, stateless, idempotent, no side effects, authentication requirements, rate limits (free/pro tiers), error handling, and data privacy. This exceeds typical expectations.
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?
The description is well-structured with sections, but contains redundancy: 'Behavioral Transparency' details appear twice (once in the main description and again after 'When NOT to use'). This could be condensed without losing information.
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?
The description covers many aspects (behavior, rate limits, error handling) but does not describe the format or structure of the successful output (e.g., what a learning path recommendation looks like). Given no output schema, this gap reduces completeness.
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 description includes an 'Args' section that describes each parameter, adding meaning beyond the input schema's type/title. For example, 'current_level: Current proficiency: beginner, intermediate, advanced' provides values. With 0% schema description coverage, this fully compensates.
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?
The description clearly states the tool's purpose: 'Recommend a personalized learning path based on student profile.' This is specific and distinct from sibling tools (e.g., analyze_student_progress, create_quiz), which focus on different tasks.
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?
The description includes explicit 'When to use' and 'When NOT to use' sections, advising to use for structured analysis and cautioning against real-time production use without human review. However, it does not explicitly contrast with sibling tools, but still provides clear guidance.
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.
v1.0.0analyze_student_progresscreate_quizgenerate_lesson_plangenerate_rubricrecommend_learning_pathScored across 5 tools
Each tool targets a distinct educational function: progress analysis, quiz creation, lesson plan generation, rubric generation, and learning path recommendation. There is no overlap in purpose, and the descriptions clearly differentiate them.
All tools follow a consistent 'verb_noun' pattern in snake_case: analyze_student_progress, create_quiz, generate_lesson_plan, generate_rubric, recommend_learning_path. The verbs are varied but the pattern is uniform, making the set predictable.
With 5 tools, the server is well-scoped for an education AI assistant. Each tool covers a major educational task without redundancy, and the count is neither too sparse nor overly heavy.
The tool set covers core educational workflows: analysis, quiz creation, lesson planning, rubric generation, and learning path recommendation. Minor gaps exist (e.g., no feedback generation or class management), but the surface is largely adequate for common teaching scenarios.
Connect your Moodle to AI assistants: courses, content, grading and reports from the chat.
AI-powered LMS course builder: 89 tools, 17 skills, SCORM/xAPI export, agentic UI
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
Generate tailored quality criteria and scoring guides from your task descriptions. Refine objectiv…
