How do I use OA-Y MCP Service?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OA-Y MCP Service get all courses" 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.

OA-Y MCP Service

by AdminRHS

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

OA-Y MCP Service

MCP for managing courses via HTTP API at oa-y.com.

Integration as MCP Server

This service supports two transport protocols for MCP integration: STDIO and StreamableHTTP.

Mode 1: STDIO (Local/Command Line)

For local integration with Cursor, Claude Desktop, or other MCP clients:

{
  "mcpServers": {
    "oa-y-mcp-service": {
      "command": "npx",
      "args": ["-y", "github:AdminRHS/oa-y-mcp-service"],
      "env": {
        "APP_ENV": "prod",
        "API_TOKEN": "your_token",
        "API_TOKEN_LIBS": "your_libs_token"
      }
    }
  }
}

Mode 2: StreamableHTTP (Remote/HTTP)

For remote integration via StreamableHTTP:

{
  "mcpServers": {
    "oa-y-remote": {
      "url": "http://your-server:3000/mcp?API_TOKEN=your_token&API_TOKEN_LIBS=your_libs_token&APP_ENV=prod"
    }
  }
}

When to use each transport:

STDIO (stdin/stdout, Desktop‑first): Ideal for Desktop apps and local IDE integrations (Cursor, Claude Desktop).
StreamableHTTP (/mcp, Browser/Agents‑first): Best for AI agents and browser/cloud clients (including proxies/tunnels).

API_TOKEN

How to get your API_TOKEN:

Go to https://oa-y.com and log in as an admin.
Open the Admin Panel and go to the API Tokens tab.
Click Create Token, enter a name, and create the token.
Copy the generated token and use it as the API_TOKEN environment variable.

API_TOKEN_LIBS

How to get your API_TOKEN_LIBS:

Go to https://libs.anyemp.com and log in as an admin.
Open the Admin Panel and go to the API Tokens tab.
Click Create Token, enter a name (e.g., "Libs API"), and create the token.
Copy the generated token and use it as the API_TOKEN_LIBS environment variable.

APP_ENV

Environment setting:

prod - Production environment (default, uses oa-y.com and libs.anyemp.com)
dev - Development/testing (uses lrn.oa-y.com and libdev.anyemp.com)

Related MCP server: canvas-lms

Available MCP Tools

This section describes all available tools for managing courses, lessons, modules, tests, and professions.

Course Management

get_courses — get a list of courses (with filters and pagination, supports profession filtering)
get_course — get a course by id
create_course — create a course (requires module IDs from create_module)
update_course — update a course (requires module IDs from create_module)

Lesson Management

get_lessons — get a list of lessons
get_lesson — get a lesson by id
create_lesson — create a lesson (use this first to get lesson IDs)
update_lesson — update a lesson

Module Management

get_modules — get a list of modules
get_module — get a module by id
create_module — create a module (requires lesson IDs from create_lesson)
update_module — update a module (requires lesson IDs from create_lesson)

Test Management

get_tests — get a list of tests
get_test — get a test by id
create_test — create a test (requires lesson ID from create_lesson, tests are attached to lessons)
update_test — update a test (requires lesson ID from create_lesson, tests are attached to lessons)

Profession Management

get_professions — get all professions (returns array with name and ID)
get_skills — get all skills (returns array with name and ID)
get_tools — get all tools (returns array with name and ID)

Creation Order

IMPORTANT: Follow the correct sequential creation order for courses, modules, lessons, and tests.

Sequential workflow:

CREATE COURSE:
- Use create_course to create the course structure
- Can start with empty modules array, will be updated later
CREATE MODULE (at least one module required):
- Use create_module to create a module
- Can start with empty lessons array
- Get module ID from the response
CREATE FIRST LESSON (at least one lesson per module required):
- Use create_lesson to create a lesson
- Get lesson ID from the response
CREATE TEST FOR LESSON (optional):
- Use create_test with the lesson ID to attach test to this lesson
- IMPORTANT: Tests are attached to lessons, not modules
- Get test ID from the response
UPDATE LESSON WITH TEST (if test was created):
- Use update_lesson to add test IDs to the lesson's tests array
CREATE NEXT LESSON (repeat steps 3-5):
- Create another lesson for the same module
- Create tests for it
- Update lesson with test IDs
- Repeat until all lessons for this module are created
UPDATE MODULE WITH ALL LESSON IDS:
- Use update_module to add all created lesson IDs to the module
- Example: lessons: ["lesson_id_1", "lesson_id_2", "lesson_id_3"]
CREATE NEXT MODULE (repeat steps 2-7):
- Create next module
- Create lessons for it
- Create tests for lessons
- Update lessons and module
- Repeat until all modules are created
UPDATE COURSE WITH ALL MODULE IDS:
- Use update_course to add all module IDs with their order
- Example: modules: [{ module: "module_id_1", order: 1 }, { module: "module_id_2", order: 2 }]

Required structure:

Course must contain at least one module
Module must contain at least one lesson
Tests are optional but attached to lessons (not modules)
Each module has ordered lessons
Each course has ordered modules

Data flow:

Course
  └─ Module 1 (order: 1)
      ├─ Lesson 1
      │   └─ Test 1 (optional)
      ├─ Lesson 2
      │   └─ Test 2 (optional)
      └─ ...
  └─ Module 2 (order: 2)
      ├─ Lesson 1
      └─ ...

Example Requests

Get Courses:

{
  "name": "get_courses",
  "arguments": { "page": 1, "limit": 10 }
}

Get Courses by Professions:

{
  "name": "get_courses",
  "arguments": {
    "professions": [68, 69],
    "difficulty": "beginner"
  }
}

Create Lesson (first):

{
  "name": "create_lesson",
  "arguments": {
    "title": "Lesson Title",
    "description": "Lesson description (optional)",
    "type": "text",
    "contentType": "standard",
    "content": "Lesson content here",
    "image": "https://example.com/lesson-image.jpg",
    "duration": 30,
    "professions": [],
    "skills": [],
    "tests": []
  }
}

Create Module (with lesson IDs):

{
  "name": "create_module",
  "arguments": {
    "title": "Module Title",
    "content": "Module description (plain text)",
    "description": "Optional detailed description",
    "videoUrl": "https://example.com/video.mp4",
    "previewImage": "https://example.com/preview.jpg",
    "lessons": ["lesson_id_from_create_lesson"]
  }
}

Note: Modules don't contain tests directly. Tests are attached to lessons.

Create Course (with module IDs):

{
  "name": "create_course",
  "arguments": {
    "title": "Course Title",
    "description": "Course description",
    "difficulty": "beginner",
    "modules": [
      {
        "module": "module_id_from_create_module",
        "order": 1
      }
    ],
    "professions": [],
    "image": "",
    "duration": 60
  }
}

Get Professions:

{
  "name": "get_professions",
  "arguments": {}
}

Get Skills:

{
  "name": "get_skills",
  "arguments": {}
}

Get Tools:

{
  "name": "get_tools",
  "arguments": {}
}

Create Test (with lesson ID):

{
  "name": "create_test",
  "arguments": {
    "title": "Test Title",
    "description": "Test description",
    "lesson": "lesson_id_from_create_lesson",
    "questions": [
      {
        "question": "What is HTML?",
        "type": "single-choice",
        "options": [
          { "text": "HyperText Markup Language", "isCorrect": true },
          { "text": "High Tech Modern Language", "isCorrect": false }
        ],
        "points": 10
      }
    ],
    "passingScore": 70,
    "timeLimit": 30
  }
}

IMPORTANT: Tests are attached to lessons, not modules. Use lesson ID from create_lesson.

Update Course (with module IDs):

{
  "name": "update_course",
  "arguments": {
    "courseId": "course_id_here",
    "title": "Updated Course Title",
    "description": "Updated course description",
    "difficulty": "intermediate",
    "modules": [
      {
        "module": "existing_module_id",
        "order": 1
      },
      {
        "module": "new_module_id_from_create_module",
        "order": 2
      }
    ]
  }
}

Course Filtering by Professions

The get_courses tool supports filtering courses by profession IDs:

Workflow:

Call get_professions to get all available professions with their IDs
Use profession IDs in get_courses with the professions parameter

Parameters:

professions - Array of profession IDs (numbers)
difficulty - Filter by difficulty: "beginner", "intermediate", "advanced"
search - Search by course name or description
page - Page number for pagination
limit - Number of courses per page
all - Get all courses without pagination

Testing

This section describes how to test the MCP service in different modes.

Testing Mode 1: STDIO (Local/Command Line)

Prerequisites:

Node.js installed
API tokens configured (see API_TOKEN and API_TOKEN_LIBS sections)

Steps:

Install dependencies:
```
npm install
```
Build the bundled version:
```
npm run build
```
This creates oa-y-mcp-service.cjs file that will be used by MCP clients.

Configure your MCP client (Cursor/Claude Desktop):

Add to your MCP settings file:

{
  "mcpServers": {
    "oa-y-local": {
      "command": "node",
      "args": ["c:/Projects/RH/oa-y-mcp-service/oa-y-mcp-service.cjs"],
      "env": {
        "APP_ENV": "prod",
        "API_TOKEN": "your_token",
        "API_TOKEN_LIBS": "your_libs_token"
      }
    }
  }
}

Restart your MCP client (Cursor/Claude Desktop)
Test the tools:
- Try calling get_professions to verify connection
- Try creating a lesson with create_lesson
- Verify that all tools are available and working

For development/debugging:

npm run dev          # Run in STDIO mode
npm run dev:inspect  # Run with Node Inspector

Testing Mode 2: StreamableHTTP (Remote/HTTP)

Prerequisites:

Node.js installed
API tokens configured (see API_TOKEN and API_TOKEN_LIBS sections)

Steps:

Install dependencies:
```
npm install
```
Start the HTTP server:
```
npm start
# or
npm run http
```
Test health endpoint:
```
curl http://localhost:3000/health
```

Configure your MCP client (Cursor/Claude Desktop):

Add to your MCP settings file:

{
  "mcpServers": {
    "oa-y-http": {
      "url": "http://localhost:3000/mcp?API_TOKEN=your_token&API_TOKEN_LIBS=your_libs_token&APP_ENV=prod"
    }
  }
}

Restart your MCP client (Cursor/Claude Desktop)
Test the tools:
- Try calling get_professions to verify connection
- Try creating a lesson with create_lesson
- Verify that all tools are available and working

For development/debugging:

npm run http:inspect  # Run HTTP server with Node Inspector

Available HTTP endpoints:

GET /mcp — StreamableHTTP handshake/stream
POST /mcp — MCP protocol endpoint
GET /health — health check
GET / — service information

Testing with public URL (localtunnel):

For testing with remote access:

Install localtunnel:
```
npm install -g localtunnel
```
Start your local server:
```
npm start
```
Create a public tunnel:
```
lt --port 3000 --local-host localhost
```

Use the provided URL in your MCP client:

{
  "mcpServers": {
    "oa-y-remote": {
      "url": "https://random-subdomain.loca.lt/mcp?API_TOKEN=your_token&API_TOKEN_LIBS=your_libs_token&APP_ENV=prod"
    }
  }
}

Deployment

This section describes how to deploy the MCP service for production use.

Deployment Mode 1: STDIO (NPM Package via GitHub)

This mode allows users to install your MCP service directly from GitHub using npx.

Requirements:

Repository pushed to GitHub
Built oa-y-mcp-service.cjs file committed to repository

Deployment Steps:

Build the bundled version:
```
npm run build
```
This creates oa-y-mcp-service.cjs — the bundled file that includes all dependencies.

Commit and push to GitHub:

git add oa-y-mcp-service.cjs
git commit -m "Build MCP service for distribution"
git push origin main

Users can now install via npx:

{
  "mcpServers": {
    "oa-y-mcp-service": {
      "command": "npx",
      "args": ["github:AdminRHS/oa-y-mcp-service"],
      "env": {
        "APP_ENV": "prod",
        "API_TOKEN": "user_token",
        "API_TOKEN_LIBS": "user_libs_token"
      }
    }
  }
}

Important:

Always build before pushing: npm run build
The built file oa-y-mcp-service.cjs must be committed to the repository
Users will download and run this file via npx

Deployment Mode 2: StreamableHTTP (Docker on Server)

This mode deploys the MCP service as an HTTP server using Docker.

Requirements:

Docker and Docker Compose installed on server
Server with public IP or domain name

Deployment Steps:

On your server, clone the repository:

git clone https://github.com/AdminRHS/oa-y-mcp-service.git
cd oa-y-mcp-service

Create .env file (optional, for custom port):
```
PORT=3000
```
Start the service with Docker Compose:
```
docker-compose up -d
```
Verify the service is running:
```
curl http://localhost:3000/health
```

Users can now connect via HTTP:

{
  "mcpServers": {
    "oa-y-remote": {
      "url": "http://your-server-ip:3000/mcp?API_TOKEN=user_token&API_TOKEN_LIBS=user_libs_token&APP_ENV=prod"
    }
  }
}

Docker Compose Configuration:

The service uses docker-compose.yml and Dockerfile:

Builds image from Node.js Alpine
Installs dependencies
Exposes port 3000 (configurable via .env)
Auto-restarts on failure

Updating the Deployment:

To update the service on the server:

git pull origin main
docker-compose down
docker-compose up -d --build

Monitoring:

View logs:

docker-compose logs -f

Check container status:

docker-compose ps

Production Recommendations:

Use a reverse proxy (nginx/traefik) for HTTPS
Set up proper firewall rules
Use environment-specific API tokens
Configure monitoring and alerts
Set up automated backups

Response Format

All responses follow the MCP (Model Context Protocol) JSON-RPC 2.0 format. See MCP documentation for details.

Available Scripts

npm run dev - Run STDIO mode (local development)
npm run dev:inspect - Run STDIO mode with Inspector
npm run http - Run HTTP server mode
npm run http:inspect - Run HTTP server with Inspector
npm start - Start HTTP server (default)
npm run build - Build bundled version (oa-y-mcp-service.cjs)

Available Tools

19 tools

create_courseD

ParametersJSON Schema

Name	Required	Description
`image`	No	Path to course image (optional, default standard image)
`title`	Yes	Course title (required, automatically generates slug)
`tools`	No	Array of tool IDs from libraries service (optional, can be empty array)
`videos`	No	Array of video URLs (optional)
`isDraft`	No	Is draft (optional, default: true)
`modules`	No	Course modules with lesson IDs (create lessons first, then add their IDs to modules)
`difficulty`	Yes	Difficulty level (required)
`description`	Yes	Course description (required)
`professions`	No	Array of profession IDs from microservice (optional, can be empty array)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create_lessonD

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Lesson type (optional)
`image`	No	Lesson image URL (optional)
`title`	Yes	Lesson title (required, automatically generates slug)
`skills`	No	Array of skill IDs from libservice (optional, can be empty array)
`content`	No	Main lesson content (HTML/Markdown, required if contentType !== "mixed")
`isDraft`	No	Is draft (optional, default: true)
`duration`	No	Lesson duration in minutes (optional, default: 0)
`videoUrl`	No	Video URL (for video type lessons)
`resources`	No	Additional resources
`contentType`	Yes	Content type (optional)
`description`	No	Lesson description (optional)
`professions`	No	Array of profession IDs from libservice (optional, can be empty array)
`contentBlocks`	No	Content blocks (required if contentType === "mixed")
`practiceExercises`	No	Practice exercises

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create_moduleD

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Module title (required, automatically generates slug)
`content`	Yes	Module description (required, plain text)
`isDraft`	No	Is draft (optional, default: true)
`lessons`	No	Array of lesson IDs (can be empty array)
`videoUrl`	No	Video URL for module (optional)
`description`	No	Module description (optional)
`previewImage`	No	Preview image URL (optional)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create_testD

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Test title (required, automatically generates slug)
`lesson`	Yes	Lesson ID (required)
`questions`	Yes	Array of test questions
`timeLimit`	No	Time limit in minutes (optional)
`description`	No	Test description (optional)
`passingScore`	No	Minimum score to pass (0-100)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_courseD

ParametersJSON Schema

Name	Required	Description	Default
`courseId`	Yes	Course ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_coursesD

ParametersJSON Schema

Name	Required	Description
`all`	No	Get all courses without pagination
`page`	No	Page number (default: 1)
`limit`	No	Number of courses per page (default: 10)
`search`	No	Search by course name or description
`difficulty`	No	Filter by difficulty level
`professions`	No	Array of profession IDs to filter courses (must be obtained via get_professions tool call)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_lessonD

ParametersJSON Schema

Name	Required	Description
`courseId`	Yes	Course ID
`lessonId`	Yes	Lesson ID
`moduleId`	Yes	Module ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_lessonsD

ParametersJSON Schema

Name	Required	Description
`all`	No	Get all lessons without pagination
`page`	No	Page number (default: 1)
`type`	No	Filter by lesson type
`limit`	No	Number of lessons per page (default: 10)
`search`	No	Search by lesson title or description
`contentType`	No	Filter by content type
`professions`	No	Array of profession IDs to filter lessons (must be obtained via get_professions tool call)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_moduleD

ParametersJSON Schema

Name	Required	Description	Default
`moduleId`	Yes	Module ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_modulesD

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (default: 1)
`limit`	No	Number of modules per page (default: 10)
`search`	No	Search by module title or description

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_professionsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_skillsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_testD

ParametersJSON Schema

Name	Required	Description	Default
`testId`	Yes	Test ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_testsD

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (default: 1)
`limit`	No	Number of tests per page (default: 10)
`search`	No	Search by test title or description

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_toolsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_courseD

ParametersJSON Schema

Name	Required	Description
`image`	No	Path to course image (optional, default standard image)
`title`	Yes	Course title (required, automatically generates slug)
`tools`	No	Array of tool IDs from libraries service (optional, can be empty array)
`videos`	No	Array of video URLs (optional)
`isDraft`	No	Is draft (optional, default: true)
`modules`	No	Course modules with lesson IDs (create lessons first, then add their IDs to modules)
`courseId`	Yes	Course ID for update
`difficulty`	Yes	Difficulty level (required)
`description`	Yes	Course description (required)
`professions`	No	Array of profession IDs from microservice (optional, can be empty array)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_lessonD

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Lesson type (optional)
`image`	No	Lesson image URL (optional)
`title`	Yes	Lesson title (required, automatically generates slug)
`skills`	No	Array of skill IDs from libservice (optional, can be empty array)
`content`	No	Main lesson content (HTML/Markdown, required if contentType !== "mixed")
`isDraft`	No	Is draft (optional, default: true)
`duration`	No	Lesson duration in minutes (optional, default: 0)
`lessonId`	Yes	Lesson ID for update
`videoUrl`	No	Video URL (for video type lessons)
`resources`	No	Additional resources
`contentType`	Yes	Content type (optional)
`description`	No	Lesson description (optional)
`professions`	No	Array of profession IDs from libservice (optional, can be empty array)
`contentBlocks`	No	Content blocks (required if contentType === "mixed")
`practiceExercises`	No	Practice exercises

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_moduleD

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Module title (required, automatically generates slug)
`content`	Yes	Module description (required, plain text)
`isDraft`	No	Is draft (optional, default: true)
`lessons`	No	Array of lesson IDs (can be empty array)
`moduleId`	Yes	Module ID for update
`videoUrl`	No	Video URL for module (optional)
`description`	No	Module description (optional)
`previewImage`	No	Preview image URL (optional)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_testD

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Test title (required, automatically generates slug)
`lesson`	Yes	Lesson ID (required)
`testId`	Yes	Test ID for update
`questions`	Yes	Array of test questions
`timeLimit`	No	Time limit in minutes (optional)
`description`	No	Test description (optional)
`passingScore`	No	Minimum score to pass (0-100)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

19 tool updatesv2.0.0Aug 30, 2026
- First observedcreate_course
- First observedcreate_lesson
- First observedcreate_module
- First observedcreate_test
- First observedget_course
- First observedget_courses
- First observedget_lesson
- First observedget_lessons
- First observedget_module
- First observedget_modules
- First observedget_professions
- First observedget_skills
- First observedget_test
- First observedget_tests
- First observedget_tools
- First observedupdate_course
- First observedupdate_lesson
- First observedupdate_module
- First observedupdate_test

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.8/5.0

Scored 2026-08-30 14:35 across 19 tools

Disambiguation4/5

Most tools are clearly distinguished by entity and action, with predictable pairs like get_course/get_courses and create_lesson/update_lesson. The lack of descriptions creates some ambiguity around closely named resources, but the naming is distinct enough for an agent to select correctly.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using get_, create_, and update_ prefixes. The use of singular nouns for mutations and plural or singular nouns for reads is predictable and uniform across the entire set.

Tool Count3/5

At 19 tools, the server is within the borderline-heavy range for a content-management domain. The count is manageable but slightly above the ideal 3-15 scope, suggesting some consolidation might improve focus.

Completeness3/5

Core entities like courses, lessons, modules, and tests have get/create/update operations, but no delete operations exist for any mutable resource. Professions, skills, and tools are read-only, which may be intentional but leaves the overall lifecycle incomplete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

FormastyOAuth
com.formasty
Create, edit, validate, publish, and inspect Formasty forms and quizzes over authenticated MCP.
App Automation Workplace & Productivity
1
reservations A
kz.tehprof.booking
Remote MCP for TehProf Booking: browse resources & availability, create & cancel reservations.
Calendar Management App Automation
82
paxaver-mcp A
io.github.Smartoire
MCP adapter for the Paxaver school community platform. Streamable HTTP, OAuth 2.1, capability auth.
Education & Learning Tools Communication
251
mcp-shorturlOAuth
io.github.AceDataCloud
MCP server for URL shortening and management
App Automation
21

Related MCP Servers

moodle-connector
Education & Learning Tools Content Management Systems
Jabir-Srj
A
license
Not graded
quality
C
maintenance
Moodle REST API client with batch downloading and MCP protocol support for Claude Code and OpenCode, enabling course management, grade checking, assignment tracking, file downloads, and more.
Updated 6 months ago (2026-03-30 00:19 UTC)
6
MIT
canvas-lms
Education & Learning Tools Content Management Systems
Drastixs
A
license
Not graded
quality
D
maintenance
MCP server for Canvas LMS with automatic OAuth authentication. Enables interaction with courses, assignments, grades, modules, discussions, quizzes, files, calendar, messaging, and more without manual API token management.
Updated 5 months ago (2026-04-05 16:16 UTC)
59 npm
MIT
mydy-lms
Education & Learning Tools Content Management Systems
Deeptanshuu
F
license
Not graded
quality
C
maintenance
An MCP server for interacting with the MyDy (Moodle-based) LMS, enabling attendance viewing, course browsing, assignment and grade checking, announcement reading, and material downloading.
Updated 5 months ago (2026-04-28 07:34 UTC)
7
-
sjtu-canvas-mcp
Education & Learning Tools File Systems
Aspirin0000
A
license
Not graded
quality
B
maintenance
Provides MCP tools to read SJTU Canvas data, download course files, and access video/subtitle resources without authentication simulation.
Updated 2 months ago (2026-07-05 14:28 UTC)
MIT