Khan Academy MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
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 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/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: '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.
Usage Guidelines4/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![khanacademyMCP MCP server](https://glama.ai/mcp/servers/aicoder2009/khanacademyMCP/badges/card.svg)](https://glama.ai/mcp/servers/aicoder2009/khanacademyMCP)

Score Badge

Copy to your README.md:

[![khanacademyMCP MCP server](https://glama.ai/mcp/servers/aicoder2009/khanacademyMCP/badges/score.svg)](https://glama.ai/mcp/servers/aicoder2009/khanacademyMCP)

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/aicoder2009/khanacademyMCP'

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