The Khan Academy MCP Server lets AI assistants search, browse, and retrieve educational content from Khan Academy without requiring an API key.
Search for videos, articles, exercises, and courses using keyword queries (e.g., "photosynthesis", "quadratic formula")
List subjects and courses: Use list_subjects to see top-level subjects and popular courses as a starting point
Browse topic hierarchies: Navigate subject/topic trees by slug and depth using get_topic_tree
Get content details: Retrieve specific videos, articles, or exercises by slug or URL with get_content
Retrieve course structures: Fetch full courses including units, lessons, and content items with get_course
Access video transcripts: Get plain text or timestamped transcripts via get_transcript, supporting Khan Academy URLs, YouTube URLs, or video IDs with multi-language support
Explore specific content types: Dedicated tools for articles, lessons, exercises, and quizzes (get_article, get_lesson, get_exercise, get_quiz)
Embed videos and build study guides: Use embed_video for video metadata and study_guide to create structured study plans
Follow predefined workflows: Chain tools together for topic exploration, course overviews, study sessions, and test preparation
Allows AI assistants to search, browse, and read Khan Academy's educational content, including videos, articles, exercises, and full course structures.
Enables fetching video transcripts and captions from YouTube videos associated with educational content.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Khan Academy MCP Server search for articles and videos about photosynthesis"
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.
An open-source Model Context Protocol (MCP) server that lets AI assistants search, browse, and read Khan Academy's educational content. No API key required.
npx khanmcpOr install globally:
npm install -g khanmcp
khanacademy-mcpRelated MCP server: Reddit MCP Server
Add this to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"khanacademy": {
"command": "npx",
"args": ["-y", "khanmcp"]
}
}
}Tool | Description |
| Search Khan Academy for videos, articles, exercises, and courses |
| List all top-level subjects and popular courses |
| Browse the subject/topic hierarchy by slug with configurable depth |
| Get details about a specific content item (video, article, exercise) |
| Get full course structure with units, lessons, and content items |
| Get video transcripts (timestamped or full text) |
| Read the full text content of a Khan Academy article |
| Get all content items in a specific lesson |
| Embed a video with thumbnail image, metadata, chapters, and optional transcript |
| Get exercise details with related study content (videos, articles) and practice URL |
| List all quizzes, unit tests, and course challenge for a course with prep material |
| Build a structured study plan for any topic |
searchquery: string — Search query (e.g., "photosynthesis", "quadratic formula")
limit?: number — Max results (1-30, default: 10)
kind?: string — "all", "video", "article", or "exercise" (default: "all")list_subjectsNo parameters. Returns all top-level subjects and popular courses.
get_topic_treeslug: string — Topic slug (e.g., "math", "science/biology")
depth?: number — Levels to fetch (0-3, default: 1)get_contentslug: string — Content slug or full URLget_courseslug: string — Course slug or URL (e.g., "math/algebra")get_transcriptslug: string — Video slug, KA URL, YouTube URL, or YouTube ID
language?: string — Language code (default: "en")
format?: string — "full", "timestamped", or "both" (default: "full")get_articleslug: string — Article slug or full URL (articles have "/a/" in the path)get_lessonslug: string — Lesson slug or full URLembed_videoslug: string — Video slug, KA URL, YouTube URL, or YouTube ID
include_transcript?: bool — Include the full transcript (default: false)
language?: string — Language code for transcript (default: "en")get_exerciseslug: string — Exercise slug or full URL (exercises have "/e/" in the path)get_quizslug: string — Course slug or URL (e.g., "math/algebra")
kind?: string — "all", "quiz", "unit-test", or "course-challenge" (default: "all")study_guidetopic: string — Topic or concept to study (e.g., "quadratic equations")
depth?: string — "quick", "standard", or "comprehensive" (default: "standard")Topic exploration:
list_subjects → get_topic_tree → get_course → get_lesson → get_content / get_transcript
Quick lookup:
search → get_content or get_article → get_transcript (if video)
Study session:
search or get_topic_tree → study_guide for review, then get_article / get_transcript for deep dives
Course overview:
get_course → pick a unit/lesson → get_lesson → get_content
Test prep:
get_quiz → review covered lessons → get_exercise for practice → get_transcript / get_article to study weak areas
git clone https://github.com/aicoder2009/khanacademyMCP.git
cd khanacademyMCP
npm install
npm run buildTest with:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.jsKhan Academy deprecated their public API in 2020. This MCP server uses:
Khan Academy's internal GraphQL API — safelisted queries for content metadata and search
YouTube transcript API — fetches video captions/subtitles
Page scraping — extracts structured data from Khan Academy web pages as a fallback
Static catalog — hardcoded top-level subjects for reliable list_subjects
All access is read-only with rate limiting (500ms between requests) and in-memory caching to be respectful of Khan Academy's servers.
No authentication — cannot access user-specific data (progress, recommendations)
Khan Academy's internal API may change without notice — static fallbacks ensure basic functionality
Transcript availability depends on YouTube captions being present
Rate-limited to avoid overloading Khan Academy's servers
MIT
Get details about a specific Khan Academy content item (video, article, or exercise). Accepts a slug or full URL. Returns title, description, type, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Content slug or full URL (e.g., 'math/algebra/v/intro-to-algebra', 'https://www.khanacademy.org/science/biology/a/intro-to-biology') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior by stating it 'Returns title, description, type, and metadata,' which adds value beyond the input schema. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose, input, and output. Every sentence earns its place: the first specifies the action and resource, the second covers input format and return values, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, input, and return values. However, without annotations or output schema, it could benefit from more behavioral context (e.g., error handling). The absence of an output schema means the description must explain returns, which it does adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the slug parameter well-documented in the schema itself (including examples). The description adds minimal value by repeating that it 'Accepts a slug or full URL,' which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific Khan Academy content item') with specific examples of item types (video, article, exercise). It distinguishes from siblings like get_course (course-level), get_topic_tree (hierarchical), get_transcript (transcript-specific), list_subjects (listing), and search (broad search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it's for 'a specific Khan Academy content item' and mentions alternatives like slug or URL, but doesn't explicitly state when to use this vs. siblings like get_course (for course-level details) or search (for broader queries). No explicit exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full structure of a Khan Academy course, including units, lessons, and content items. Use list_subjects or search to find course slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Course slug or URL (e.g., 'math/algebra', 'science/ap-biology', 'computing/computer-programming') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns ('full structure... including units, lessons, and content items'), which is useful behavioral context. However, it doesn't disclose other behavioral traits like whether it's read-only (implied by 'Get'), error handling, rate limits, or authentication needs. The description adds some value but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place: the first defines what the tool does, and the second provides critical context for when to use it. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with 100% schema coverage and no output schema, the description is reasonably complete. It explains the purpose, distinguishes from siblings, and provides usage guidance. However, without annotations or output schema, it could benefit from more behavioral details (e.g., response format, error cases) to be fully comprehensive for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the single 'slug' parameter. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., no extra examples or constraints). According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full structure of a Khan Academy course', specifying it includes 'units, lessons, and content items'. It distinguishes from siblings like 'get_content' (likely single item), 'get_topic_tree' (different hierarchy), 'get_transcript' (different resource), 'list_subjects' (list vs. get), and 'search' (search vs. get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance by stating 'Use `list_subjects` or `search` to find course slugs', naming two alternative tools for discovering course slugs before using this tool. This clearly defines the prerequisite context and differentiates usage from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Khan Academy's subject/topic hierarchy. Given a topic slug, returns its subtopics and content items. Use list_subjects first to get valid slugs, then drill down.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Topic slug or URL (e.g., 'math', 'science/biology', 'math/algebra') | |
| depth | No | How many levels deep to fetch (0=this topic only, 1=immediate children, max 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the tool's function (browsing hierarchy, returning subtopics/content) and the drilling-down workflow. However, it doesn't mention potential limitations like rate limits, error conditions, or response format details, which would be helpful for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every word earns its place with no redundancy or wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (hierarchy browsing with parameters), no annotations, and no output schema, the description does well by explaining the purpose, workflow, and relationship to other tools. However, it could be more complete by briefly mentioning what the return structure looks like (e.g., 'returns a tree structure') since there's no output schema to provide that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain slug format examples or depth implications beyond the schema's description). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Browse') and resource ('Khan Academy's subject/topic hierarchy'), specifies the action ('returns its subtopics and content items'), and distinguishes it from sibling tools by mentioning 'list_subjects' as a prerequisite. This provides specific, actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Given a topic slug') and provides clear guidance on prerequisites ('Use `list_subjects` first to get valid slugs, then drill down'), including naming an alternative tool for the initial step. This gives complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the transcript of a Khan Academy video. Returns timestamped text and a full-text version. Accepts a KA video slug/URL or YouTube URL/ID.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Video slug, KA URL, YouTube URL, or YouTube video ID (e.g., 'math/algebra/v/intro-to-algebra', 'https://www.youtube.com/watch?v=NybHckSEQBI') | |
| language | No | Language code for the transcript (default: 'en') | en |
| format | No | Output format: 'full' (plain text), 'timestamped' (with timestamps), 'both' (default: 'full') | full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what the tool returns ('timestamped text and a full-text version'), it doesn't describe error handling, rate limits, authentication requirements, or what happens with invalid inputs. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and output, the second specifies the input parameters. Every sentence earns its place with no wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and parameter guidance but lacks details on return values, error conditions, or operational constraints. For a tool with 3 parameters and no structured safety/behavior annotations, the description is adequate but incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning the parameter types in natural language ('KA video slug/URL or YouTube URL/ID') but doesn't provide additional syntax, format details, or usage examples that aren't already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the transcript'), resource ('of a Khan Academy video'), and output details ('timestamped text and a full-text version'). It distinguishes this tool from siblings like get_content or get_course by focusing specifically on video transcripts rather than general content or course structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it accepts 'KA video slug/URL or YouTube URL/ID', but it doesn't explicitly state when to use this tool versus alternatives like get_content (which might also provide transcript data) or when not to use it (e.g., for non-video content). No explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all top-level Khan Academy subjects and popular courses. Returns subject names, slugs, and descriptions. Use this as a starting point to explore Khan Academy's content.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format ('subject names, slugs, and descriptions') which is helpful, but doesn't mention behavioral traits like rate limits, authentication needs, pagination, or whether it's read-only. The description doesn't contradict annotations (none exist), but leaves gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose and return values, the second provides usage guidance. Every sentence earns its place with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains what the tool does and when to use it, though it could benefit from more behavioral context (e.g., read-only nature, any limitations). The absence of an output schema makes the return format disclosure in the description particularly valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter context is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all top-level Khan Academy subjects and popular courses' with specific verbs ('List') and resources ('subjects and popular courses'). It distinguishes from siblings by focusing on top-level subjects as a starting point, though not explicitly contrasting with tools like 'get_course' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Use this as a starting point to explore Khan Academy's content.' This implies when to use it (initial exploration) but doesn't explicitly state when not to use it or name alternatives like 'get_content' or 'search' for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Khan Academy for videos, articles, exercises, and courses. Returns matching content with titles, types, and URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., 'photosynthesis', 'quadratic formula', 'intro to python') | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'matching content with titles, types, and URLs' but doesn't mention important behavioral aspects like rate limits, authentication requirements, pagination, error handling, or whether this is a read-only operation. For a search tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first defines the search scope and target resources, the second describes the return format. There's zero waste or redundancy, and it's appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and moderate complexity (search functionality with 2 parameters), the description is incomplete. It doesn't explain the return format in detail (beyond mentioning titles, types, and URLs), doesn't address behavioral constraints, and provides no usage guidance relative to sibling tools. For a search tool without structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (query and limit). The description doesn't add any parameter-specific information beyond what's in the schema, such as search syntax examples or result ordering. This meets the baseline expectation when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search Khan Academy') and resources targeted ('videos, articles, exercises, and courses'), distinguishing it from siblings like get_content, get_course, or list_subjects which appear to retrieve specific content rather than perform searches. It provides a comprehensive verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_content or get_course. It doesn't mention prerequisites, exclusions, or comparative use cases with sibling tools, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_contentget_courseget_topic_treeget_transcriptlist_subjectssearchEach tool has a clearly distinct purpose: get_content retrieves details of a specific item, get_course provides course structure, get_topic_tree explores hierarchical topics, get_transcript fetches video transcripts, list_subjects lists top-level subjects, and search performs general searches. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern using snake_case: get_content, get_course, get_topic_tree, get_transcript, list_subjects, and search. The verbs 'get' and 'list' are used appropriately, and there are no deviations in naming conventions throughout the set.
With 6 tools, the server is well-scoped for exploring and retrieving Khan Academy content. Each tool serves a specific, non-redundant function, covering key operations like browsing, searching, and fetching details without being overly sparse or bloated.
The tool set provides comprehensive coverage for browsing, searching, and retrieving Khan Academy content, including subjects, courses, topics, items, and transcripts. A minor gap is the lack of tools for user-specific actions like tracking progress or saving content, but this is reasonable for a content-focused server, and agents can still perform core exploration tasks effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Search and query nTop's knowledge base and engineering guides from AI applications.
Search verified Claude Code plugins and skills; fetch portable SKILL.md sources. Read-only.
Read-only Reddit search API for AI agents: posts, comments, comment trees, subreddit rules.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aicoder2009/khanacademyMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
