What can you do with this server?

The SkillOps MCP server provides five AI-powered tools to automate key EdTech operations tasks, turning repetitive workflows into single commands: * Triage support queries (triage_support_query): Classify incoming student support tickets by category and urgency, draft empathetic replies, and flag tickets requiring human escalation. * Generate re-engagement messages (generate_reengagement_message): Create personalized win-back emails and/or WhatsApp messages for inactive students, tailored by name, course, days inactive, last completed module, and completion percentage. * Analyze course feedback (analyze_course_feedback): Batch-process up to 50 raw feedback strings to extract sentiment, top themes, key complaints, key praises, and prioritized improvement suggestions. * Generate weekly cohort reports (batch_generate_reports): Compute cohort metrics (completion rates, at-risk students, top performers) deterministically in Python from inline records or a CSV file, then produce a structured narrative report with recommended actions. * Create course outlines (create_course_outline): Generate detailed course structures including modules, lessons, estimated durations, learning objectives, hands-on projects, and assessments — configurable by topic, audience level, duration, and delivery format.

Which integrations are available for this server?

Integrates with Google Gemini API to classify support tickets, generate re-engagement messages, analyze course feedback, produce cohort reports, and create course outlines for EdTech operations.

How do I use SkillOps MCP?

1. Click on "Install 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., "@SkillOps MCP Triage: 'I paid but can't open the videos!'" 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.

SkillOps MCP

by Ultr0nX

Overview Schema Related Servers Score Discussions

Python

Local

SkillOps MCP

AI-powered operations automation for EdTech teams. Five Model Context Protocol tools that turn hours of repetitive weekly busywork — support triage, re-engagement outreach, feedback analysis, progress reporting, and course design — into a single sentence typed into any MCP client.

Python 3.11+ License: MIT MCP Compatible Powered by Gemini Tests

Related MCP server: Educhain MCP Server

What is SkillOps MCP?

EdTech operations, growth, and product teams spend hours every week on repetitive, judgment-light work:

Reading and categorizing every incoming support ticket
Hand-writing re-engagement emails for students who went quiet
Skimming hundreds of feedback comments to find what to fix
Assembling the weekly cohort progress report
Drafting course outlines from a blank page

It's necessary work, but it scales linearly with headcount and quietly burns people out.

SkillOps MCP turns each of those into a single command. It's a server that exposes five purpose-built tools to any MCP client (Claude Desktop, Claude Code, or others). A support lead pastes a ticket and gets an instant triage with a ready-to-send reply. A growth manager generates a personalized win-back message in seconds. A product manager drops in a batch of feedback and gets a structured, prioritized analysis.

The design principle is "deterministic work in code, language work in the model." Anything that must be correct — cohort averages, at-risk thresholds, CSV parsing, input validation — is computed in plain Python so the numbers are never hallucinated. Only the genuinely language-shaped work (writing, classifying, summarizing) is delegated to the LLM. That LLM is Google's Gemini, running free on gemini-2.5-flash via the Google AI Studio free tier — no credit card required.

What is MCP? (60-second primer)

The Model Context Protocol (MCP) is an open standard (created by Anthropic) that lets AI assistants call external tools in a uniform way — think of it as "USB-C for AI tools." Instead of every app inventing its own plugin format, a single MCP server exposes tools that any MCP client can discover and call.

   You ──talk──▶  MCP CLIENT  ──MCP protocol──▶  MCP SERVER  ──▶  your code
 (English)      (Claude Desktop,   (JSON-RPC over     (this project)
                 Claude Code…)       stdio)

You type plain English into the client.
The client (an AI assistant) decides which tool to call and with what arguments.
The server (this project) runs the tool and returns a result.

You never speak the protocol yourself — the client translates your English into a tool call for you. SkillOps MCP is the server half: it provides the five EdTech tools; you bring any MCP client to drive them.

The five tools

#	Tool	What it does	Example you'd type
1	`triage_support_query`	Classifies a support ticket (category + urgency), drafts an empathetic reply, and flags whether a human is needed.	"Triage: 'I paid but can't open the videos!'"
2	`generate_reengagement_message`	Writes a personalized email + WhatsApp win-back message for an inactive student.	"Re-engage Priya — 12 days inactive, 45% through Web Dev."
3	`analyze_course_feedback`	Turns a batch of raw feedback into sentiment scores, themes, complaints, praises, and prioritized fixes.	"Analyze these 40 reviews for the Python course."
4	`batch_generate_reports`	Computes cohort metrics in Python, then has the model write the weekly narrative report.	"Weekly report from students.csv for the Spring cohort."
5	`create_course_outline`	Produces a full course outline: modules, lessons, durations, projects, assessments.	"Outline an 8-week beginner 'Intro to SQL' course."

Full input/output details for each are in the Tool reference.

Architecture

SkillOps MCP is built in clean, testable layers. Each layer has one job and is independently verifiable.

┌──────────────────────────────────────────────────────────────────┐
│  MCP CLIENT   (Claude Desktop · Claude Code · any MCP client)     │
│  You type plain English here. The client picks the tool + args.   │
└───────────────────────────────┬──────────────────────────────────┘
                                 │  MCP protocol (JSON-RPC over stdio)
                                 ▼
┌──────────────────────────────────────────────────────────────────┐
│  SERVER LAYER     src/skillops_mcp/server.py                      │
│  • FastMCP app, name = "SkillOps MCP"                             │
│  • 5 thin @mcp.tool adapters (docstrings become tool descriptions)│
│  • Loads .env, configures stderr logging, then mcp.run()          │
└───────────────────────────────┬──────────────────────────────────┘
                                 ▼
┌──────────────────────────────────────────────────────────────────┐
│  TOOL LAYER       src/skillops_mcp/tools/*.py                     │
│  Each tool: validate input → build prompt → call model → format   │
│  • support · outreach · feedback · reports · curriculum           │
│  • reports.py computes all metrics in PURE PYTHON (no LLM math)   │
└──────────────┬───────────────────────────────┬───────────────────┘
               ▼                                ▼
┌──────────────────────────┐    ┌──────────────────────────────────┐
│  MODELS    models/        │    │  UTILS    utils/                 │
│  schemas.py               │    │  gemini_client.py — API wrapper  │
│  Pydantic v2 input models │    │    (retries, JSON mode, logging) │
│  + enums (urgency, etc.)  │    │  formatters.py — text rendering  │
└──────────────────────────┘    └───────────────┬──────────────────┘
                                                 │  Google Gemini API (free tier)
                                                 ▼
                                          gemini-2.5-flash

Layer responsibilities

Layer	File(s)	Responsibility
Server	`server.py`	Speaks MCP. Registers the 5 tools, each as a thin adapter whose docstring is shown to the AI as the tool's description. Logs to stderr (never stdout — that would corrupt the stdio transport).
Tools	`tools/*.py`	The actual work. Each follows the same shape: validate → prompt → call → format. `reports.py` additionally computes cohort statistics in pure Python.
Models	`models/schemas.py`	Pydantic v2 models enforce every tool's input contract (required fields, enums, numeric bounds) before any API call. Bad input becomes a friendly `Error: …` string, never a crash.
Gemini client	`utils/gemini_client.py`	One place for all LLM calls: exponential-backoff retries on 429/5xx, fails fast on 4xx, Gemini-native JSON mode, strict parsing, and structured logging on every call.
Formatters	`utils/formatters.py`	Turns structured data into the clean, plain-text reports you see in chat.

Key design choices

Numbers are computed, not generated. In batch_generate_reports, averages, at-risk lists, top performers, and assignment rates are calculated in Python. The model only writes the narrative around those facts — so a report can never invent a statistic.
Validation before spend. Pydantic rejects bad input before a single token is sent, saving API calls and returning precise error messages.
No database. Everything is in-memory; reports read from inline data or a CSV path. Zero infrastructure to run.
One client, one retry policy. Every tool calls the same GeminiClient, so resilience and logging are uniform.

How a request flows (step by step)

Take "Triage this ticket: 'I paid but can't open the videos!'"

You type that into your MCP client (e.g. Claude Code).
The client recognizes it matches the triage_support_query tool and calls the server over stdio with { "query": "I paid but can't open the videos!" }.
server.py receives the call and forwards it to tools/support.py.
support.py validates the input with the SupportQueryInput Pydantic model. (Blank/empty → instant Error: string, no API call.)
It builds a system + user prompt and calls GeminiClient.call_json(...).
gemini_client.py sends the request to Gemini in JSON mode, retrying on rate limits / server errors, and parses the JSON reply into a dict.
support.py formats that dict into the readable triage report via formatters.py.
The string travels back through the server → client → and appears in your chat.

Total time: a couple of seconds. Total cost on the free tier: $0.

Tech stack

Concern	Choice	Why
Language	Python 3.11+	Modern typing, broad availability
MCP framework	FastMCP	Minimal, decorator-based MCP servers
LLM	Google Gemini (`gemini-2.5-flash`) via `google-genai`	Free tier, fast, native JSON output
Validation	Pydantic v2	Declarative input contracts, great errors
Config	python-dotenv	`.env`-based secrets, never hardcoded
Data	Built-in csv / json	No heavy deps for parsing
Logging	Built-in logging	Structured, stderr-safe
Testing	pytest + pytest-asyncio	Fast, fully mocked, offline

Project structure

skillops-mcp/
├── src/
│   └── skillops_mcp/
│       ├── __init__.py
│       ├── server.py              # MCP entry point — registers all 5 tools
│       ├── tools/
│       │   ├── support.py         # triage_support_query
│       │   ├── outreach.py        # generate_reengagement_message
│       │   ├── feedback.py        # analyze_course_feedback
│       │   ├── reports.py         # batch_generate_reports (Python metrics + narrative)
│       │   └── curriculum.py      # create_course_outline
│       ├── models/
│       │   └── schemas.py         # Pydantic v2 input models + enums
│       └── utils/
│           ├── gemini_client.py   # Gemini API wrapper: retries, JSON mode, logging
│           └── formatters.py      # Plain-text output rendering helpers
├── tests/
│   ├── conftest.py                # mock_client fixture; API-key isolation
│   ├── test_support.py
│   ├── test_outreach.py
│   ├── test_feedback.py
│   ├── test_reports.py
│   └── test_curriculum.py
├── examples/
│   ├── sample_feedback.json       # 10 feedback strings for the feedback tool
│   ├── sample_students.csv        # 7 student rows for the reports tool
│   └── sample_queries.txt         # 3 support tickets for the triage tool
├── demo.py                        # interactive terminal demo (no MCP client needed)
├── .mcp.json                      # MCP client config (Claude Code auto-detects it)
├── .env.example                   # copy to .env and add your free Gemini key
├── .gitignore                     # ignores .env (your secret stays local)
├── pyproject.toml                 # package metadata + `skillops-mcp` entry point
├── requirements.txt               # runtime dependencies
├── requirements-dev.txt           # + pytest
└── README.md

Prerequisites

Python 3.11 or newer (python --version)
pip
A free Google Gemini API key (how to get one)
(Optional) An MCP client — Claude Code or Claude Desktop — to use the tools conversationally. You can also try everything with the bundled demo.py and no client at all.

Installation

# 1. Clone
git clone https://github.com/<your-username>/skillops-mcp.git
cd skillops-mcp

# 2. (Recommended) create a virtual environment
python -m venv .venv && source .venv/bin/activate      # Windows: .venv\Scripts\activate

# 3. Install the package (editable) — this also installs all dependencies
pip install -e .
#    For development/tests, also: pip install -r requirements-dev.txt

# 4. Configure your free Gemini key
cp .env.example .env
#    then open .env and set GEMINI_API_KEY=...

# 5. Smoke-test it (no API call, fully offline)
pytest

pip install -e . registers the package so it's importable from anywhere and creates a skillops-mcp console command. (You can also pip install -r requirements.txt if you prefer not to install the package itself.)

Getting your free Gemini API key

The default engine is Gemini's free tier — no credit card, no UPI, no billing of any kind.

Go to https://aistudio.google.com/apikey
Sign in with any Google account
Click Create API key → choose "Create API key in a new project" (Google makes the free project for you)
Copy the key (looks like AIzaSy...)
Paste it into your .env:
```
GEMINI_API_KEY=AIzaSy...your-key...
```

Free-tier note: Google AI Studio's free tier has generous per-minute/day rate limits — plenty for personal use and demos — and (on the free tier) Google may use prompts to improve its products. For production traffic, enable paid usage in Google Cloud.

Configuration

All configuration is via environment variables (loaded from .env):

Variable	Required	Default	Purpose
`GEMINI_API_KEY`	Yes	—	Your free Google AI Studio key
`GEMINI_MODEL`	No	`gemini-2.5-flash`	Which Gemini model to use (any free-tier Flash model works)
`SKILLOPS_LOG_LEVEL`	No	`INFO`	`DEBUG` · `INFO` · `WARNING` · `ERROR`
`SKILLOPS_MAX_RETRIES`	No	`3`	Retry attempts on rate-limit / server errors

The server loads .env from the project root regardless of the directory it's launched from, so MCP clients can start it from anywhere.

How to use it — three ways

Way 1 — Quick demo in the terminal (no MCP client needed)

The fastest way to see all five tools working:

python demo.py

This opens a friendly menu that calls the same tool functions an MCP client would, and prints the output. Great for a first look or a screen-share. (Requires GEMINI_API_KEY in .env.)

Way 2 — Inside Claude Code (recommended for daily use)

Claude Code auto-detects the committed .mcp.json:

{
  "mcpServers": {
    "skillops": {
      "command": "python",
      "args": ["-m", "skillops_mcp.server"]
    }
  }
}

Make sure you ran pip install -e . (so python -m skillops_mcp.server resolves).
Reload the editor window so Claude Code re-reads .mcp.json.
Type /mcp — you should see skillops with its 5 tools. Approve/trust it if prompted.
Now just chat in plain English:
"Use the skillops tools to triage this ticket: 'I paid but can't open the videos!'"

Way 3 — Inside Claude Desktop

Add this to your claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "skillops": {
      "command": "python",
      "args": ["-m", "skillops_mcp.server"],
      "env": {
        "GEMINI_API_KEY": "your-free-gemini-key-here"
      }
    }
  }
}

Restart Claude Desktop. The five tools appear and you talk to them in plain English.

WSL note: if your Python lives in WSL but Claude Desktop runs on Windows, set "command": "wsl" and "args": ["python", "-m", "skillops_mcp.server"].

Tool reference

Each tool returns a clean, human-readable string (with a RAW JSON appendix for power users). You can call them by describing what you want — the client maps your words to the right tool and arguments.

1. `triage_support_query`

Analyze a student support message and return a structured triage.

Parameter	Type	Required	Default	Notes
`query`	string	Yes	—	The raw support message
`student_name`	string		`"Student"`	For personalizing the reply
`course_name`	string		`null`	The course they're enrolled in

You type:

Triage this ticket: "I paid but can't open the videos, it's been 2 days!"

You get back (real output):

SUPPORT TRIAGE COMPLETE
──────────────────────────────────────────────────
Category: technical_issue
Urgency: high — Student has paid but is fully blocked from content for two days.
Escalate to Human: Yes — Payment + access issues need a human to check backend systems.
Estimated Resolution: 1-2 business days
Tags: access_issue, payment_verification, video_access, content_lock

SUGGESTED RESPONSE:
"Dear Student, I'm very sorry to hear you're having trouble accessing the course
videos despite having paid, especially after two days. Our team is actively
investigating to get you access as quickly as possible, and we'll reach out
shortly with an update. Thank you for your patience."

Output fields: category (one of technical_issue, billing, course_content, mentor_support, certificate, refund, general), urgency (critical/high/medium/low), urgency_reason, suggested_response, escalate_to_human, escalation_reason, estimated_resolution_time, tags.

2. `generate_reengagement_message`

Write a personalized win-back message for an inactive student.

Parameter	Type	Required	Default	Notes
`student_name`	string	Yes	—	First name
`course_name`	string	Yes	—	Course they enrolled in
`days_inactive`	int	Yes	—	Days since last activity
`last_completed_module`	string		`null`	Last module they finished
`completion_percentage`	float		`null`	e.g. `45.5`
`channel`	string		`"email"`	`email` · `whatsapp` · `both`

You type:

Generate a re-engagement message for Priya — 12 days inactive in Web Development, last finished "CSS Basics", 45% complete. Channel: both.

You get back (illustrative):

RE-ENGAGEMENT MESSAGE READY
──────────────────────────────────────────────────

EMAIL
Subject: You're closer than you think, Priya

Hi Priya, you crushed CSS Basics and you're already 45% through Web Development —
real momentum, still right where you left it. The next module is where the fun
starts. It takes ~20 minutes to get back in the flow. Want to pick up where you
stopped?  → Resume Module 6: JavaScript Foundations

WHATSAPP
Hey Priya! You're 45% through Web Dev and CSS Basics is behind you. The next
module is a fun one — jump back in? Takes ~20 mins

PERSONALIZATION HOOKS:
  • Referenced her 45% progress
  • Named her last completed module (CSS Basics)
  • Lowered the barrier with a "20 minutes" framing

Recommended send time: Tuesday 10am or Thursday 6pm

3. `analyze_course_feedback`

Analyze a batch of raw feedback in a single model call (not one per item).

Parameter	Type	Required	Default	Notes
`feedback_list`	list[str]	Yes	—	1–50 items (extras truncated with a note)
`course_name`	string		`null`	For context
`analysis_focus`	string		`"balanced"`	`balanced` · `complaints_only` · `praises_only` · `actionable_only`

You type:

Analyze this feedback for Python Basics: [paste the 10 lines from examples/sample_feedback.json]

You get back (illustrative):

COURSE FEEDBACK ANALYSIS
──────────────────────────────────────────────────
Items analyzed: 10
Overall sentiment: positive (score: 0.45)
Breakdown: positive 6 | neutral 1 | negative 3

TOP THEMES:
  • Video length & pacing (×3, negative) — "Videos are too long…"
  • Mentor support (×2, positive) — "got a response within hours"

KEY COMPLAINTS:  • Videos too long  • Need more practice problems
KEY PRAISES:     • Clear instruction  • Real career outcomes
IMPROVEMENT SUGGESTIONS:
  • [high / medium] Split long videos into 5–8 min segments
  • [high / low] Add a solutions bank for practice problems

EXECUTIVE SUMMARY:
Net-positive sentiment driven by instruction and mentor support; clearest win is
shorter videos and more solved practice problems.

4. `batch_generate_reports`

Generate a weekly cohort report. Metrics are computed in Python; only the narrative comes from the model.

Parameter	Type	Required	Default	Notes
`data_source`	string	Yes	—	`"inline"` or `"csv"`
`students_data`	list[dict]	conditionally	`null`	Required when `inline`
`csv_path`	string	conditionally	`null`	Required when `csv`
`report_week`	string		`null`	e.g. `"Jun 16–22, 2026"`
`cohort_name`	string		`null`	e.g. `"Spring Cohort"`

CSV columns: name, course, completion_pct, last_active_days_ago, quiz_avg_score, assignments_submitted, total_assignments (missing columns are reported clearly; a sample is in examples/sample_students.csv).

You type:

Generate this week's report from examples/sample_students.csv for the "Spring Cohort", week "Jun 16–22, 2026".

You get back (illustrative):

Spring Cohort — Weekly Progress Report
──────────────────────────────────────────────────
Cohort: Spring Cohort | Week: Jun 16–22, 2026 | Students: 7

COHORT METRICS
  Average completion:     58.4%      ← computed in Python
  Average quiz score:     68.9
  Assignment completion:  57.1%
  At-risk students:       3
  Top performers:         2

RECOMMENDED ACTIONS:
  • [urgent] Personal outreach to Divya Patel (25 days inactive) — Success Team
  • [this_week] Nudge sequence for Sneha & Priya — Growth

At-risk = inactive > 7 days or completion < 30%. Top performer = completion > 80% and quiz avg > 75. These thresholds are pure Python — never the model's guess.

5. `create_course_outline`

Generate a complete, structured course outline.

Parameter	Type	Required	Default	Notes
`topic`	string	Yes	—	e.g. `"Python for Data Science"`
`audience_level`	string	Yes	—	`absolute_beginner` · `beginner` · `intermediate` · `advanced`
`duration_weeks`	int		`8`	Total weeks
`hours_per_week`	float		`5.0`	Study hours/week
`delivery_format`	string		`"self_paced"`	`self_paced` · `live_cohort` · `hybrid`
`include_projects`	bool		`true`	Include hands-on projects

You type:

Outline an 8-week beginner course on "Intro to SQL", 5 hrs/week, self-paced, with projects.

You get back (illustrative):

Intro to SQL: Query Real Data with Confidence
──────────────────────────────────────────────────
Total: ~40.0 hours

LEARNING OUTCOMES:
  • Write SELECT queries with filtering, sorting, and joins
  • Model a small relational database from scratch
  • Aggregate and report on real datasets

MODULES:
  Module 1: SQL Foundations  (5.0h)
      1. [video] What is a Database? (15 min)
      2. [exercise] Your First SELECT (40 min)
      Project: Query a movie database
      Module quiz included
  ...
FINAL PROJECT: Build & query an e-commerce schema end-to-end

Error handling

Every tool returns a clean Error: … string instead of crashing the server. The cases handled:

Situation	What you see
Missing API key	`Error: GEMINI_API_KEY not set. Add it to your .env file.`
API down after retries	`Error: Gemini API unavailable after 3 retries. Check your API key and network.`
Non-retryable API error (e.g. 400)	`Error: Gemini API error (400): <message>` — fails fast, no wasted retries
Un-parseable model output	`Error: Could not parse Gemini's response as JSON. Raw response: …`
Invalid input (empty feedback, bad enum, etc.)	`Error: <specific validation message>`
CSV file not found	`Error: CSV file not found at path: <path>`
CSV missing columns	`Error: CSV missing required columns: <list>`

Validation runs before any API call, so bad input fails instantly and for free.

Testing

The suite is fully offline — every Gemini call is mocked, so no API key and no network are needed, and it costs nothing.

pip install -r requirements-dev.txt
pytest                 # 22 tests
pytest -v              # verbose
pytest tests/test_reports.py   # one file

Each tool is tested for: a valid call (mocked model response), invalid/empty input, and the missing-API-key path. reports.py additionally has tests proving the Python-computed metrics are correct and that CSV errors are handled.

tests/test_curriculum.py .....   tests/test_reports.py  ......
tests/test_feedback.py    ....   tests/test_support.py  ...
tests/test_outreach.py    ....   ===== 22 passed =====

Engineering highlights

For reviewers, the parts worth a look:

Deterministic-vs-generative split. tools/reports.py computes every statistic in Python and hands the model only the facts — a report can't hallucinate a number. This is the project's core design idea.
Resilient API client. utils/gemini_client.py retries only what's worth retrying (429 + 5xx) with exponential backoff, fails fast on 4xx, uses Gemini's native JSON mode, and logs every call structurally.
Validation as a first-class layer. models/schemas.py (Pydantic v2) enforces every contract before spend; errors are turned into friendly strings, never stack traces.
Provider-swappable by design. The entire LLM dependency lives behind one small client class — the project started on Anthropic Claude and moved to free Gemini by changing one file.
Stdio-safe logging. Logs go to stderr so they never corrupt the MCP stdout transport — a subtle but real correctness requirement for MCP servers.
Tested, typed, documented. Type hints and docstrings on every function; 22 offline tests; no bare except; no print; no hardcoded secrets.

Extending it — add your own tool

Adding a sixth tool takes three steps:

Define the input model in models/schemas.py:

class MyToolInput(BaseModel):
    text: str = Field(..., min_length=1)

Write the tool in tools/mytool.py following the standard shape:

def run(text: str, client: GeminiClient | None = None) -> str:
    try:
        params = MyToolInput(text=text)
    except ValidationError as exc:
        return f"Error: {fmt.validation_message(exc)}"
    try:
        client = client or GeminiClient()
    except MissingAPIKeyError as exc:
        return f"Error: {exc}"
    data = client.call_json(SYSTEM_PROMPT, user_prompt, tool_name="my_tool")
    return _format_output(data)

Register it in server.py:

@mcp.tool
def my_tool(text: str) -> str:
    """One-line description the AI will read to decide when to call this."""
    return mytool.run(text=text)

Add a tests/test_mytool.py mirroring the existing tests and you're done.

Troubleshooting

Symptom	Fix
`Error: GEMINI_API_KEY not set`	Add the key to `.env`, or to the `env` block of your MCP client config.
`/mcp` doesn't list `skillops`	Run `pip install -e .`, then reload your editor. Or add it explicitly: `claude mcp add skillops python -m skillops_mcp.server`.
`No module named skillops_mcp`	You skipped `pip install -e .` (or you're in a different Python env / venv than the one the client launches).
Gemini `429` errors	Free-tier rate limit — wait a moment and retry; the client already backs off automatically.
Server "hangs" when run directly	That's correct — `python -m skillops_mcp.server` waits silently for an MCP client over stdio. Use `demo.py` to interact directly.
Claude Desktop on Windows can't find Python in WSL	Use `"command": "wsl"`, `"args": ["python", "-m", "skillops_mcp.server"]`.

FAQ

Does this cost anything? No. It runs on Gemini's free tier — no credit card, no UPI. The test suite is free too (fully mocked).

Do I need Claude or Anthropic? No. SkillOps MCP is the server. Any MCP client can drive it — Claude Code, Claude Desktop, or others. The LLM doing the work inside is Gemini.

Why MCP instead of a REST API or a CLI? Because the value is being inside the tool the team already uses. With MCP, a support lead triages a ticket without leaving their AI chat — no new app, no copy-pasting into a separate service.

Can I use a different model? Yes — set GEMINI_MODEL in .env to any free-tier Gemini model. Swapping providers entirely is a one-file change in utils/gemini_client.py.

Is my .env safe to commit? No — and it's already in .gitignore. Your key stays on your machine.

Why I built this

The highest-leverage AI automation isn't flashy — it's the quiet, repetitive operational work that consumes an EdTech team's week. Triaging tickets, chasing inactive learners, reading feedback, and assembling reports are tasks where human judgment matters at the edges but the bulk is mechanical. By packaging that work as MCP tools, it lives directly inside the assistant the team already uses, the deterministic parts stay deterministic, and the model only does the writing. The result turns "an afternoon of busywork" into "a single sentence" — backed by a clean, tested, provider-agnostic codebase that's easy to extend with the next workflow.

License

Released under the MIT License. See LICENSE (or the badge above) for details.

Available Tools

5 tools

analyze_course_feedbackA

Analyze a batch of student course feedback. Returns sentiment scores, top themes, key complaints, key praises, and actionable improvement suggestions. Input is a JSON array of feedback strings.

ParametersJSON Schema

Name	Required	Description	Default
`feedback_list`	Yes	List of raw feedback strings (1-50 items).
`course_name`	No	Course name for context, if known.
`analysis_focus`	No	One of "balanced", "complaints_only", "praises_only", "actionable_only".	balanced

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It describes the analysis as returning structured outputs but does not mention side effects, read-only nature, error handling, or limitations (e.g., input size limits are only in the schema). The description does not contradict annotations (none exist), but it is insufficient for an agent to safely invoke the tool without additional assumptions.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the primary purpose and outputs. No extraneous information, perfectly scoped for quick comprehension.

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

Completeness4/5

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

Given that an output schema exists to document return values and the tool is a non-destructive analysis, the description covers the main purpose, input type, and high-level output categories. It lacks details on error behavior or scalability, but for this type of tool, it is largely complete.

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

Parameters3/5

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

Input schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema—it only restates that input is a JSON array of feedback strings. The optional parameters 'course_name' and 'analysis_focus' are not mentioned in the description, missing an opportunity to clarify their purpose.

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

Purpose5/5

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

The description clearly states the tool analyzes a batch of student course feedback and lists specific outputs: sentiment scores, top themes, complaints, praises, and improvement suggestions. It uses a specific verb 'analyze' and resource 'course feedback', and the sibling tools handle unrelated tasks (report generation, outline creation, etc.), so there is no ambiguity.

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

Usage Guidelines3/5

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

The description implies when to use the tool (when you have a batch of student feedback to analyze) but does not explicitly state when not to use it or provide alternatives. Given the siblings are clearly different, the usage is reasonably implied, but no explicit guidance is given.

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

batch_generate_reportsA

Generate a structured weekly student progress report from raw student data. Accepts either a list of student records or a CSV file path. Returns an executive summary, at-risk students list, top performers, and recommended actions.

ParametersJSON Schema

Name	Required	Description
`data_source`	Yes	"inline" to use students_data, or "csv" to read csv_path.
`students_data`	No	List of student record dicts (required when inline).
`csv_path`	No	Path to a CSV file (required when data_source is "csv").
`report_week`	No	Reporting period label, e.g. "Jun 16-22, 2026".
`cohort_name`	No	Name of the student cohort.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden for behavioral disclosure. It does not mention whether the tool is read-only, destructive, requires authentication, or has rate limits. It only describes input and output formats, missing a safety statement.

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

Conciseness5/5

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

The description is three sentences, front-loaded with the primary action, and every sentence contributes essential information. No redundant or extraneous content.

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

Completeness4/5

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

Given the presence of an output schema, return values need not be explained. The description covers purpose, input modes, and key output components. It does not mention error handling, prerequisites (e.g., file existence), or performance limits, but overall it is adequate for a batch generation tool.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by grouping parameters into inline vs CSV modes, but the schema already describes each parameter's role. No additional semantics beyond what the schema provides.

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

Purpose5/5

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

The description clearly states the verb 'generate', the resource 'structured weekly student progress report', and the context 'from raw student data'. It also specifies input modes and output components, making it distinct from siblings like 'analyze_course_feedback' or 'create_course_outline'.

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

Usage Guidelines4/5

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

The description implies usage for batch report generation by describing input options and output, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The siblings are distinct enough that confusion is minimal.

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

create_course_outlineA

Generate a detailed, structured course outline for any topic and audience level. Returns modules, lessons per module, learning objectives, estimated durations, and assessment ideas.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The course topic, e.g. "Python for Data Science".
`audience_level`	Yes	One of "absolute_beginner", "beginner", "intermediate", "advanced".
`duration_weeks`	No	Total course duration in weeks (default 8).
`hours_per_week`	No	Expected study hours per week (default 5.0).
`delivery_format`	No	One of "self_paced", "live_cohort", "hybrid".	self_paced
`include_projects`	No	Whether to include hands-on projects (default True).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It lists what the tool returns but does not disclose how it generates the outline (e.g., AI model used, limitations, or any side effects). The output description is useful but not comprehensive for behavioral transparency.

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

Conciseness5/5

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

The description is two sentences with no unnecessary words. It front-loads the core purpose and lists output components efficiently. Every sentence earns its place.

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

Completeness5/5

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

Given the tool has an output schema, the description need not elaborate on return values. It already covers the key output items. With good schema coverage and no nested objects, the description is complete for this moderately complex tool.

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

Parameters3/5

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

The input schema has 100% coverage, so the baseline is 3. The description adds no new meaning beyond restating that the tool works for any topic and audience level, which is already implied by the parameter descriptions. No additional semantics provided.

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

Purpose5/5

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

The description clearly states the tool generates a detailed, structured course outline and lists specific output components (modules, lessons, objectives, durations, assessment ideas). It distinguishes itself from sibling tools like analyze_course_feedback or batch_generate_reports which perform different tasks.

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

Usage Guidelines3/5

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

The description implies the tool can be used for any topic and audience level, but does not explicitly state when to use it over alternatives or provide exclusion criteria. Sibling tools are sufficiently different, so no guidance is needed for distinguishing, but lack of explicit usage context lowers the score.

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

generate_reengagement_messageA

Generate a personalized re-engagement outreach message for an inactive student. Returns subject line, email body, and WhatsApp-friendly short message. Use for growth team automation.

ParametersJSON Schema

Name	Required	Description	Default
`student_name`	Yes	Student's first name.
`course_name`	Yes	The course they enrolled in.
`days_inactive`	Yes	Number of days since their last activity.
`last_completed_module`	No	Name of the last module they completed, if known.
`completion_percentage`	No	Course completion percentage (0-100), if known.
`channel`	No	Target channel — "email", "whatsapp", or "both".	email

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description must carry behavioral weight. It states the output includes three components but does not disclose how the message is generated (e.g., AI model usage) or any constraints like token limits or personalization depth.

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

Conciseness5/5

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

Two sentences efficiently convey the tool's purpose, outputs, and usage context. Every word adds value, with no redundancy.

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

Completeness4/5

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

Given the existence of a separate output schema, the description adequately notes the return types. It covers the core intent and expected outputs, though it could mention the generation methodology or rate limits for completeness.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already details all parameters. The description adds 'personalized' as context but does not enhance meaning beyond schema descriptions. Baseline 3 applies.

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

Purpose5/5

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

The description explicitly states the tool generates a personalized re-engagement message for an inactive student, listing specific outputs (subject line, email body, WhatsApp-friendly short message). This clearly differentiates it from siblings like 'analyze_course_feedback' or 'triage_support_query' which serve different purposes.

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

Usage Guidelines4/5

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

The description includes 'Use for growth team automation,' indicating appropriate context. However, it does not explicitly state when not to use or mention alternatives among siblings, leaving some ambiguity.

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

triage_support_queryA

Analyze a student support query and return category, urgency level, suggested response, and escalation flag. Use this to automate support ticket triage for EdTech operations teams.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The raw student support message text.
`student_name`	No	Student's name for personalization (default "Student").	Student
`course_name`	No	The course the student is enrolled in, if known.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It does not disclose how classification is performed (e.g., rules or AI), potential latency, or error scenarios. The outputs are listed but not explained beyond names.

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

Conciseness5/5

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

Two sentences, front-loaded with the core purpose and target audience. No extraneous information; every sentence adds value.

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

Completeness4/5

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

Given the output schema exists and parameters are clear, the description covers return values and primary use. However, behavioral transparency is missing, making it slightly incomplete for a tool with no annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning (e.g., 'raw student support message' for query) but does not provide deeper context beyond the schema.

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

Purpose5/5

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

The description clearly states the tool's purpose: analyzing a student support query and returning specific outputs (category, urgency, etc.). It distinguishes from sibling tools (e.g., analyze_course_feedback is for course feedback, not support queries).

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

Usage Guidelines3/5

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

The description identifies the use case (automating support ticket triage) but does not explicitly mention when not to use it or suggest alternatives when the query is not about support.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 23, 2026
- First observedanalyze_course_feedback
- First observedbatch_generate_reports
- First observedcreate_course_outline
- First observedgenerate_reengagement_message
- First observedtriage_support_query

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct aspect of EdTech operations: feedback analysis, report generation, course outline creation, re-engagement messages, and support triage. There is no overlap in functionality.

Naming Consistency4/5

All tool names follow a verb_noun pattern using snake_case, e.g., 'analyze_course_feedback' and 'create_course_outline'. The verb 'batch_generate' is slightly inconsistent with the simpler 'generate' in another tool, but still clear.

Tool Count5/5

Five tools cover the core operations of a skill-focused educational platform without being excessive or insufficient. Each tool serves a well-defined purpose.

Completeness4/5

The set covers feedback analysis, reporting, course outline creation, student re-engagement, and support triage. Missing basic CRUD for courses or student profiles, but the focus on analytics and automation is coherent.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Caplia AOAuth
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2

Related MCP Servers

MCP Content Curation Server
Education & Learning Tools Content Management Systems
alexandrekumagae
F
license
B
quality
D
maintenance
A Model Context Protocol server that provides AI-driven tools to categorize, tag, and optimize educational content using GPT-4.
Updated a year ago (2025-08-01 00:54 UTC)
3
6
-
Educhain MCP Server
Education & Learning Tools Developer Tools RAG Systems
Anudeep-CodeSpace
F
license
B
quality
D
maintenance
An MCP server that utilizes Google Gemini and the educhain library to generate educational content such as MCQs, flashcards, and lesson plans. It provides specialized tools and resources for building structured learning materials directly within MCP-compatible clients like Claude Desktop.
Updated a year ago (2025-07-12 06:50 UTC)
2
-
Gradescope MCP Server
Education & Learning Tools Developer Tools App Automation
Yuanpeng-Li
A
license
A
quality
F
maintenance
An MCP server that enables AI assistants to interact with Gradescope for course management, grading workflows, and regrade reviews. It provides instructors and TAs with tools for assignment management, individual or batch grading, and rubric manipulation.
Updated 4 months ago (2026-05-13 07:00 UTC)
33
7
MIT
Canvas Agent
Education & Learning Tools Project Management Communication
hughsibbele
A
license
A
quality
B
maintenance
MCP server that connects AI assistants to Instructure Canvas LMS, enabling teachers and administrators to manage courses, assignments, grades, and more through natural language.
Updated 19 days ago (2026-08-18 15:29 UTC)
80
28
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ultr0nX/skillops-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SkillOps MCP

Table of Contents

What is SkillOps MCP?

What is MCP? (60-second primer)

The five tools

Architecture

How a request flows (step by step)

Tech stack

Project structure

Prerequisites

Installation

Getting your free Gemini API key

Configuration

How to use it — three ways

Way 1 — Quick demo in the terminal (no MCP client needed)

Way 2 — Inside Claude Code (recommended for daily use)

Way 3 — Inside Claude Desktop

Tool reference

1. triage_support_query

2. generate_reengagement_message

3. analyze_course_feedback

4. batch_generate_reports

5. create_course_outline

Error handling

Testing

Engineering highlights

Extending it — add your own tool

Troubleshooting

FAQ

Why I built this

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `triage_support_query`

2. `generate_reengagement_message`

3. `analyze_course_feedback`

4. `batch_generate_reports`

5. `create_course_outline`