What can you do with this server?

This server is an MCP (Model Context Protocol) server that provides ed-tech workflows, educational content discovery, AI-assisted authoring, and tutoring capabilities to external clients. * Run liveness checks via health_check. * Search educational YouTube videos with language, result count, and safe-search options. * Retrieve educational documents enriched with complementary videos via find_documents. * Execute a LangGraph document + video discovery workflow with search-term expansion, traceable execution steps, and structured results (run_workflow). * Generate lesson/quiz/project content and research articles through agent workflows. * Author curriculum content end-to-end: search graph nodes, validate lessons/quizzes/projects/test boilerplate, save authored lesson trees to the backend, and scaffold/validate mock tests. * Run a Socratic tutor for interactive teaching turns. * Support project mentor review by collecting review context and producing project reviews. * Integrate with Supabase RPCs, DuckDuckGo/Tavily web search, YouTube Data API v3, LangGraph/LangChain, Redis caching, and backend embedding/RAG services.

Which integrations are available for this server?

Provides document retrieval from a Supabase database, enabling AI agents to search for educational documents enriched with related videos. Provides YouTube video search for educational content using the YouTube Data API v3.

How do I use ed-tech-system-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., "@ed-tech-system-mcp Find documents about machine learning with related 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.

ed-tech-system-mcp

by paulocymbaum

Overview Schema Related Servers Score Discussions

Python

Remote

ed-tech-system-mcp

Domain-Driven MCP (Model Context Protocol) server for ed-tech workflows. The server exposes validated MCP tools backed by LangGraph agents, web search, and YouTube video discovery — all organized with Clean Architecture and DDD. Document embedding and retrieval live in the backend (ed-tech-system-backend embedding service); the MCP server no longer runs RAG.

What this project does

External MCP clients call MCP tools that validate input with Pydantic, delegate to application workflows and LangGraph agents, and reach external systems through domain ports implemented in the infrastructure layer.

MCP tools

Tool	Module	Purpose
`health_check`	`custom_tools`	Liveness probe
`search_youtube`	`custom_tools`	Educational YouTube search
`build_lesson_enrichment_query`	`custom_tools`	Expand lesson metadata into 4–5 search terms for document/video lookup
`research_article`	`custom_tools_agent_workflows`	Research article generation workflow
`content_generation`	`custom_tools_agent_workflows`	Lesson/quiz/project content generation
`author_lesson_pipeline`	`custom_tools_authoring`	Graph leaf → generate → validate → save (draft/publish)
`search_graph_nodes`	`custom_tools_authoring`	Curriculum graph leaf search
`validate_lesson` / `validate_quiz` / `validate_project` / `validate_test_boilerplate`	`custom_tools_authoring`	Content validation
`save_to_backend`	`custom_tools_authoring`	Persist authored lesson tree via backend RPCs
`generate_mock_test_structure` / `validate_mock_test`	`custom_tools_authoring`	Mock assessment scaffolding
`socratic_tutor`	`custom_tools_socratic`	Socratic tutor turn
`collect_project_review_context` / `project_review`	`custom_tools_project_review`	Project mentor review

Handlers use MCP tool caching (when enabled), latency logging, privileged auth where required, and domain error mapping at the protocol boundary.

Integrations

Capability	Integration
Curriculum graph + authoring RPCs	Supabase RPCs via authoring backend client (anon + manager JWT)
Web search	DuckDuckGo / Tavily
Video discovery	YouTube Data API v3
Agent orchestration	LangChain / LangGraph
Caching	Redis when `CACHE_ENABLED=true`
Document embedding / RAG	Backend `ed-tech-system-backend` embedding service + `mcp-find-documents` edge function

Related MCP server: mcp-canon

Architecture

Clean Architecture under src/mcp_server/. Dependency rule: Domain has no framework I/O; Infrastructure implements Domain ports; Interface and Application depend inward only.

entrypoint → interface → application → domain ← infrastructure

Layer	Path	Responsibility
domain	`domain/`	Entities, ports, validators, curriculum enums — no MCP/LangGraph/Supabase
application	`application/`	LangGraph `agents/`, runners, LLM routing, authoring services
interface	`interface/`	MCP tools (`custom_tools*.py`), validation, error mapping
infrastructure	`infrastructure/`	Supabase, search, YouTube, Groq, Redis, cache adapters
entrypoint	`main.py`, `wiring.py`, `settings.py`, …	Bootstrap and composition root only

Changelog folders use the same names plus tests, performance, code-health, refactor — see ARCHITECTURE.md § Changelog layer names.

Read next: ARCHITECTURE.md (layer rules, tree, anti-patterns) · AGENTIC_ARCHITECTURE.md (graphs / tools) · OBSERVABILITY.md (execution traces).

Quick start

Prerequisites

Python 3.12 (see requires-python in pyproject.toml)
uv — environment and dependency manager
Doppler CLI (recommended for secrets) or a local gitignored .env

Install

uv python install 3.12
uv sync --all-groups

Configure secrets

Secrets never enter git. Use Doppler (team) or a local .env (solo dev).

doppler login
./scripts/doppler/setup-local.sh
./scripts/doppler/bootstrap-from-env-example.sh   # first time only — uploads placeholders
# Fill real values in the Doppler dashboard → ed-harness-system

Required variables: APP_ENV, SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY, YOUTUBE_API_KEY.

Optional: GROQ_API_KEY (only when an LLM path is invoked — lazy-init at first use), TAVILY_API_KEY, LOG_LEVEL (applied at bootstrap via configure_logging()). Staging/production also require CACHE_ENABLED=true and REDIS_URL (local/CI keep the default off).

See ENVIRONMENT_SETUP.md for the full secrets workflow.

Run the MCP server

# With Doppler
doppler run -- uv run mcp-server

# With local .env (APP_ENV=development)
uv run mcp-server

Inspect traces in tests

Traces are captured programmatically by workflow_trace.py and workflow_llm_trace.py and asserted in pytest. See OBSERVABILITY.md for trace field details and debugging patterns.

Development

Day-to-day commands

uv sync --frozen              # after pulling lockfile changes
uv run mcp-server             # start server
uv run ruff check src/        # lint
uv run ruff format --check src/
uv run mypy src/              # type check
uv run pytest                 # tests (143 cases as of 2026-07-21)

Engineering backlog

Audit findings are triaged into backlog/BACKLOG.md (RICE-ranked, traceable to changelog audits). As of 2026-07-21: 23 done, 6 deferred (adapter HTTP implementation, profiling, trace IDs).

Add dependencies

uv add some-package           # runtime
uv add --group dev some-tool  # dev only

Do not use pip install in this repo — it bypasses the lockfile.

Quality gates (CI parity)

uv sync --frozen --all-groups
uv run ruff check src/
uv run mypy src/
npm run lint:architecture   # layer imports + boundary patterns (also runs on git push)
uv run pytest

Git hooks: Husky pre-commit runs public-repo safety checks (sensitive files, tracked leaks, secret scanners); pre-push re-checks tracked safety, scans pushed commits for secret content, then runs architecture lint — neither blocks the other tier.

Run quality-gate commands from the repository root (ed-tech-system-mcp/), not ui/. The same scripts are also available inside ui/ via npm run hooks:test and npm run lint:architecture.

Project layout

.
├── src/mcp_server/
│   ├── domain/              # Entities, ports, validators, enums
│   ├── application/         # Agents, runners, LLM routing, authoring services
│   │   └── agents/          # LangGraph packages (content_generation, socratic, …)
│   ├── interface/           # MCP tools + validation
│   ├── infrastructure/      # Adapters (search, video, LLM, cache, clients)
│   ├── wiring.py            # Composition root
│   ├── settings.py
│   └── main.py              # mcp-server entry
├── tests/                   # pytest + architecture lint
├── changelog/               # Agent memory: {DATE}/{LAYER}/ (local)
├── scripts/                 # Doppler, hooks, Render, dev helpers
├── docs/assets/             # README screenshots
├── ARCHITECTURE.md          # Layer boundaries (canonical)
├── AGENTIC_ARCHITECTURE.md  # Agent graphs and tool orchestration
├── OBSERVABILITY.md         # Workflow UI, trace replay
└── ENVIRONMENT_SETUP.md     # uv, secrets, CI, MCP client config

Documentation index

See the documentation matrix at the end of this file for canonical docs and changelog artifacts.

MCP client integration

{
  "mcpServers": {
    "ed-tech-system": {
      "command": "doppler",
      "args": ["run", "--", "uv", "--directory", "/absolute/path/to/ed-tech-system-mcp", "run", "mcp-server"]
    }
  }
}

Alternative patterns (local .env, uv launcher) are in ENVIRONMENT_SETUP.md § MCP client integration.

Documentation matrix

Read the minimum doc set for your task. Do not load everything.

Canonical docs (repo root)

Document	Read when
README.md	First visit — overview, quick start, MCP tools
ARCHITECTURE.md	Any code change — layers, ports/adapters, deps per layer, file layout, anti-patterns
AGENTIC_ARCHITECTURE.md	LangGraph/LangChain agents, LLM wiring, tool taxonomy, DB/web/video flows
OBSERVABILITY.md	Execution traces and debugging
ENVIRONMENT_SETUP.md	`uv`, lockfile, deps, env vars, `ruff`/`mypy`/`pytest`, CI, MCP client setup

Conflict resolution: ARCHITECTURE.md wins on layer boundaries; AGENTIC_ARCHITECTURE.md wins on orchestration semantics.

Engineering backlog

Document	Read when
backlog/BACKLOG.md	RICE-ranked tasks from audits; status tracking
backlog/RICE.md	Scoring rubric and priority formula for backlog items

Changelog memory (`changelog/{DATE}/{LAYER}/`)

Local engineering memory (often gitignored). {LAYER} must match an architecture layer or audit folder:

domain · application · interface · infrastructure · entrypoint · tests · performance · code-health · refactor

File pattern	Purpose
`INVESTIGATION{N}.md`	Scope and gaps before coding
`IMPLEMENTATION{N}.md`	Execution checklist and status
`CODE_REVIEW{N}.md`	Pre-merge review findings
`TEST{N}.md`	Behavior catalog before writing tests
`HOMOLOGATION.md`	Coverage verdict after tests pass
`PERFORMANCE_AUDIT{N}.md`	Performance bottleneck findings
`CODE_HEALTH_AUDIT{N}.md`	Maintainability / dead-code findings
`REFACTOR{N}.md`	Merged refactor actions from audits
`LOOP_BREAK{N}.md`	Recursive-loop parameters and iteration log

Pairing: IMPLEMENTATION{N} ↔ INVESTIGATION{N}; CODE_REVIEW{N} ↔ same {N}. Full protocol: .cursor/rules/changelog-agent-memory.mdc.

Quick routing

Code in a layer?        → ARCHITECTURE.md (+ AGENTIC_ARCHITECTURE.md if agents/tools/LLM)
Traces / debugging?     → OBSERVABILITY.md
Environment / CI?       → ENVIRONMENT_SETUP.md
Secrets / Doppler?      → ENVIRONMENT_SETUP.md § Secrets & safety
Tests / merge gate?     → pytest + quality gates in ENVIRONMENT_SETUP.md
Audits / cleanup?       → backlog/BACKLOG.md

License

MIT

Available Tools

4 tools

find_documentsB

Retrieve educational documents enriched with complementary videos.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`video_limit`	No
`document_limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`videos`	Yes
`documents`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Given the lack of annotations, the description carries the full burden. It indicates a read-only retrieval operation but does not disclose return format, pagination, or side effects. The existence of an output schema partially mitigates this, but more detail would be beneficial.

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 a single, efficient sentence with no unnecessary words. It front-loads the core action and resource.

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

Completeness3/5

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

For a simple retrieval tool with an output schema, the description provides a high-level purpose but lacks parameter explanations and usage context. It is minimally adequate but leaves gaps about how the tool behaves with different inputs.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It adds context about the type of documents (educational) and videos (complementary) but fails to explain the purpose of parameters like 'query', 'video_limit', and 'document_limit'. The description does not clarify how these are used together.

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 'retrieve' and the specific resource 'educational documents enriched with complementary videos', distinguishing it from sibling tools like search_youtube (which focuses on videos) and health_check (a monitoring tool).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like search_youtube or run_workflow, nor does it specify any prerequisites or exclusions.

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

health_checkA

Verify the MCP server is running.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states 'verify' without specifying behavior on failure (e.g., error or return value). There is no mention of side effects or additional context, making it minimally transparent.

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 a single, concise sentence that perfectly conveys the tool's purpose with zero wasted words.

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

Completeness3/5

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

Given the tool has zero parameters and a simple purpose, the description is minimal but adequate. However, it could mention the presence of an output schema or return value for better completeness.

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

Parameters4/5

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

No parameters exist, and schema coverage is trivially 100%. Per guidelines, zero parameters warrants a baseline score of 4. The description adds no parameter information beyond what the schema provides, but none is needed.

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: verifying the MCP server is running. It uses a specific verb and resource, and distinguishes well from sibling tools like search_youtube, find_documents, and run_workflow.

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?

No explicit guidance on when to use this tool versus alternatives. While the context implies it should be used before other operations to ensure server availability, the description does not provide explicit context exclusions or alternatives.

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

run_workflowC

Execute the document + video discovery LangGraph workflow.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`video_limit`	No
`document_limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`trace`	No
`videos`	Yes
`documents`	Yes
`video_count`	Yes
`search_terms`	Yes
`document_count`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose any behavioral traits such as side effects, resource usage, or whether the workflow is synchronous. This is a significant gap for a workflow execution tool.

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

Conciseness4/5

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

The description is a single concise sentence with no superfluous words, but it sacrifices important details. It earns its place but could be expanded slightly without losing conciseness.

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

Completeness2/5

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

Despite having an output schema, the description is too brief for a workflow tool that likely has complex behavior. It does not explain what the workflow does beyond the name, nor how parameters affect execution.

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?

The input schema has 0% description coverage and the description does not explain the meaning or constraints of any parameter (query, video_limit, document_limit). This leaves the agent without crucial information.

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

Purpose4/5

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

The description clearly states it executes a discovery workflow involving documents and videos, which distinguishes it from sibling tools that are individual components (health_check, search_youtube, find_documents). However, 'LangGraph' is jargon and could be clarified.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus calling the sibling tools directly, nor are there any prerequisites or conditions mentioned.

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

search_youtubeC

Search for educational YouTube videos matching a query.

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`language`	No	en
`max_results`	No
`safe_search`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`videos`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and description lacks any disclosure of behavioral traits such as side effects, authentication needs, rate limits, or response behavior for a search tool.

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?

Single sentence of seven words, front-loaded with core action and resource, no redundancy; earns its place with zero waste.

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

Completeness2/5

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

Given 4 parameters and an output schema, the description is too sparse; it doesn't explain return values, usage constraints, or how parameters interact, leaving the agent with insufficient context.

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?

Schema description coverage is 0% and description adds no meaning to the four parameters (query, language, max_results, safe_search) beyond the bare schema types and defaults.

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?

Description clearly states the tool searches for educational YouTube videos matching a query, with a specific verb and resource, and distinguishes from sibling tools like health_check and find_documents.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; no exclusions or context provided beyond the basic purpose.

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.

4 tool updatesv0.1.0Jul 29, 2026
- First observedfind_documents
- First observedhealth_check
- First observedrun_workflow
- First observedsearch_youtube

Install Server

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

TDQS

B3/5.0

Disambiguation4/5

Tools are distinct: health_check is server status, search_youtube targets only videos, find_documents focuses on documents with videos, and run_workflow executes a combined workflow. Minimal overlap.

Naming Consistency4/5

All tools use snake_case with a verb_noun pattern, though health_check is noun_verb. The pattern is consistent and readable.

Tool Count2/5

With 4 tools, the server feels too sparse for an 'ed-tech system.' The core functionality (search, documents, workflow) is minimal, leaving many expected operations uncovered.

Completeness2/5

The server lacks CRUD operations for resources, user management, and other typical ed-tech features. The tool set is focused on discovery only, which is incomplete for the broad server name.

Maintenance

ActivityActive

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

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15215
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748

Related MCP Servers

production-grade-mcp-agentic
Agent Orchestration AI & Machine Learning
FareedKhan-dev
A
license
Not graded
quality
D
maintenance
A production-grade MCP server designed for multi-tenant, authenticated, and observable AI agent systems, enabling secure tool execution across heterogeneous data sources.
Updated 5 months ago (2026-04-19 05:18 UTC)
62
MIT
mcp-canon
RAG Systems Knowledge & Memory Search
tripcher
A
license
A
quality
C
maintenance
Universal MCP knowledge server for LLM agents, powered by local RAG, providing domain-specific best practices and playbooks across software engineering, marketing, video editing, and other knowledge areas.
Updated 6 months ago (2026-03-18 07:54 UTC)
3
MIT
langgraph-clean-arch
Agent Orchestration Developer Tools
FranciscoValadao
F
license
Not graded
quality
C
maintenance
MCP server implementing clean architecture with LangGraph for building and managing agent workflows.
Updated 2 months ago (2026-06-23 03:47 UTC)
-
The Culture MCP Server
Social Media AI & Machine Learning Databases
Dc-4nderson
F
license
Not graded
quality
C
maintenance
MCP server for The Culture, a fashion-focused social media app, exposing Supabase database operations and Hugging Face model inference as tools for use in Claude Code, n8n agents, and the Larry orchestrator.
Updated 2 months ago (2026-07-04 17:24 UTC)
-

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/paulocymbaum/ed-tech-system-mcp'

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

ed-tech-system-mcp

What this project does

MCP tools

Integrations

Architecture

Quick start

Prerequisites

Install

Configure secrets

Run the MCP server

Inspect traces in tests

Development

Day-to-day commands

Engineering backlog

Add dependencies

Quality gates (CI parity)

Project layout

Documentation index

MCP client integration

Documentation matrix

Canonical docs (repo root)

Engineering backlog

Changelog memory (changelog/{DATE}/{LAYER}/)

Quick routing

License

Available Tools

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

Changelog memory (`changelog/{DATE}/{LAYER}/`)