Provides tools to interact with Kendo UI for Angular documentation, enabling AI assistants to list Angular components, retrieve component topics and APIs, read documentation articles, and fetch demo source code.
Allows browsing, searching, and extracting code examples from the public Kendo UI for Angular documentation, enabling AI assistants to access Kendo UI component details, topics, API references, and demo source code.
Click on "Deploy 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., "@kendo-angular-unofficial-mcp list all Kendo Angular components"
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.
A free, open-source Model Context Protocol (MCP) server that allows AI assistants (like Claude, Roo Code, and Cline) to browse, search, and extract code examples directly from the public Kendo UI for Angular documentation.
This project serves as a community-driven, accessible alternative to official premium MCPs, enabling developers to harness the power of LLMs with Kendo UI without requiring a subscription for the documentation integration.
🚀 Zero Configuration: Works via standard input/output (stdio), meaning no network ports or complex setups are required.
🧠 Extremely Token-Optimized: Utilizes an advanced tree-grouping algorithm to compress component indexes. Shared data files in demos are automatically truncated to type definitions + a single sample record, reducing token consumption by up to 91% compared to raw output.
🔬 AST-Based Parsing: Reads documentation directly from Gatsby's page-data.json AST instead of scraping rendered HTML. This produces cleaner Markdown, eliminates CSS selector fragility, and reduces the fetch payload significantly. Falls back to HTML scraping with Cheerio if the AST is unavailable.
💻 Live Demo Code Extraction: Automatically discovers demo examples embedded in documentation pages and exposes their source code. The AI can fetch real, runnable Angular code from any documented feature.
⚡ In-Memory Caching: Prevents rate-limiting and speeds up AI responses by caching fetched documentation for 24 hours.
🛡️ Type-Safe: Built with the latest high-level @modelcontextprotocol/sdk and zod for strict parameter validation.
Related MCP server: Angular MCP Server
This server exposes five specialized tools to the AI:
list_kendo_components — Lists all available Kendo Angular components (e.g., Grid, Buttons, Dropdowns).
list_component_topics — Given a component ID, retrieves its documentation index/topics (e.g., Data Binding, Filtering, Editing). Filters out deep API references to keep context clean.
list_component_api — Retrieves deep API references for a component: @Input(), @Output(), classes, directives, and interfaces.
read_kendo_doc — Reads a specific documentation article and returns it as clean Markdown. Includes a list of available demo examples at the end that can be fetched with read_demo_source.
read_demo_source — Fetches the source code files for a specific demo example. Returns the full component code and intelligently truncates large shared data files to their type definitions + one sample record.
You don't need to clone the repository if you just want to use it. You can run it directly via npx (requires Node.js installed on your machine).
Add the following configuration to your Claude Desktop config file:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"kendo-angular-unofficial": {
"command": "npx",
"args": [
"-y",
"kendo-angular-unofficial-mcp"
]
}
}
}
Note: Restart Claude Desktop after updating the configuration.
If you are using VS Code with an MCP-compatible AI extension like Cline or Roo Code, you can easily add this server:
Open the Command Palette (Ctrl + Shift + P or Cmd + Shift + P).
Search for Cline: MCP Servers (or your extension's equivalent) to open the cline_mcp_settings.json file.
Add the following configuration:
{
"mcpServers": {
"kendo-angular-unofficial": {
"command": "npx",
"args": [
"-y",
"kendo-angular-unofficial-mcp"
]
}
}
}
If you want to contribute, modify the scraping logic, or run it locally from source:
Clone the repository:
git clone https://github.com/EremesNG/kendo-angular-unofficial-mcp.git
cd kendo-angular-unofficial-mcp
Install dependencies:
npm install
Build the TypeScript code:
npm run build
Connect your local build to your AI Client: Edit your MCP settings file (Claude Desktop or VS Code) to point to your local Node instance. Note: If you are on Windows, remember to escape your backslashes (e.g., C:\\path\\to\\dist\\index.js).
{
"mcpServers": {
"kendo-angular-local": {
"command": "node",
"args": [
"/absolute/path/to/kendo-angular-unofficial-mcp/dist/index.js"
]
}
}
}
Once connected, you can ask your AI assistant things like:
"Can you check the Kendo UI documentation and tell me what components are available?"
"Read the Kendo Angular Grid excel export documentation and write a component that implements a custom fetchData callback."
"Use the Kendo API tool to check what @Input properties are available for the <kendo-grid-column> component."
"Read the Grid filtering docs and fetch the demo source code so I can see a working example."
This is an unofficial, community-driven project. It is not affiliated with, endorsed by, or sponsored by Progress Software Corporation. Kendo UI and Telerik are trademarks of Progress Software Corporation. This tool solely extracts publicly available information from the web for educational and developmental purposes.
Given a component ID (e.g., 'grid'), returns a list of detailed API references (components, directives, interfaces, services) available for that component.
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | The component identifier in the URL (e.g., 'grid'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the output as a list but does not detail any behavioral aspects like no side effects, authentication, or rate limits. For a simple read-only tool, it's adequate but minimal.
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?
Single sentence, direct and to the point. No unnecessary words, effectively communicates 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's simplicity (1 parameter, no output schema), the description is fairly complete. It states the input and what is returned (components, directives, etc.). Could mention output format, but not essential for a list of API references.
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?
With schema coverage at 100%, the description adds little beyond the schema. The parameter 'componentId' is clearly described in both, but the description provides no extra syntactic or formatting details.
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 returns a list of detailed API references for a given component ID, using a specific verb 'returns' and resource 'list of API references'. It distinguishes from siblings like list_component_topics and list_kendo_components.
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 when API references for a component are needed, but does not explicitly state when to use it over alternatives or provide exclusions. The example helps, but no formal guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a component ID (e.g., 'grid'), returns a list of subtopics and articles available for that component. Note: For deep API references (components, directives, classes), use the 'list_component_api' tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| componentId | Yes | The component identifier in the URL (e.g., 'grid', 'buttons', 'dropdowns'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It describes the operation as returning data, but does not explicitly confirm it is read-only or mention any side effects, auth requirements, or potential pitfalls. For a simple list tool, this is adequate but not exhaustive.
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?
Two sentences, front-loaded with purpose and immediately followed by usage guidance. 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?
For a simple list tool with one parameter and no output schema, the description covers purpose, parameter semantics, and usage alternatives. It could optionally mention the return format (e.g., list of strings or objects), but omission is minor given the tool's straightforward nature.
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 coverage is 100%. The description adds an example ('grid', 'buttons', 'dropdowns') and notes the identifier is from the URL, which is helpful context but does not significantly extend the schema's own parameter 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?
Description clearly states it returns a list of subtopics and articles given a component ID. It distinguishes itself from sibling list_component_api by noting the alternative use case.
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?
Explicitly tells when to use list_component_api instead (for deep API references), providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a list of all main Kendo UI for Angular components available in the documentation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation (retrieves a list), which is non-destructive. However, with no annotations, it doesn't elaborate on response format or potential limitations, but its simplicity makes this acceptable.
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?
A single, concise sentence that is front-loaded and to the point. No extraneous information.
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?
For a simple list retrieval with no parameters and no output schema, the description adequately explains the tool's purpose. It lacks details on the list's content (e.g., names only), but given the tool's simplicity, it is largely complete.
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?
No parameters exist, so the description does not need to provide parameter details. Schema coverage is 100%, meeting the baseline for 0 params.
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 retrieves a list of Kendo UI for Angular components. It distinguishes from siblings like list_component_api (API) and list_component_topics (topics), though 'main' is slightly vague.
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?
No guidance is provided on when to use this tool versus alternatives like list_component_api or list_component_topics. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the source code files for a specific Kendo UI demo example. Use the metaUrl values listed in the 'Demos' section of read_kendo_doc output.
| Name | Required | Description | Default |
|---|---|---|---|
| metaUrl | Yes | The demo metaurl path (e.g., 'grid/data-operations/directive/filtering/'). Obtained from read_kendo_doc output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the read-only nature implicitly but does not detail potential errors, authentication needs, or return format. It is adequate but not rich.
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?
Two sentences, both essential. The first sentence states the action, the second provides critical usage guidance. 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?
For a simple one-parameter read tool with no output schema, the description adequately covers purpose and input source. It could mention error handling or output nature but is largely complete given the tool's simplicity.
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 coverage is 100%, so the schema already describes metaUrl well. The description repeats that metaUrl comes from read_kendo_doc output, which is also in the schema description. Adds little extra meaning beyond the schema.
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 it 'Fetches the source code files for a specific Kendo UI demo example', specifying the verb and resource. It differentiates from sibling tools like list_component_api or read_kendo_doc by focusing on demo source code retrieval.
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 directs the agent to use metaUrl values from read_kendo_doc output, providing clear context. It does not mention when not to use this tool or alternatives, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a specific Kendo UI documentation article and returns it in Markdown format. Includes a list of available demo examples at the end. Use read_demo_source to fetch demo source code.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The relative path of the article (e.g., '/grid/data-binding/basics'). Remember to include the component prefix if you extracted it from a grouped list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the tool returns an article in Markdown format with a list of demos. Being a read-only operation, no destructive behavior exists. Lacks error handling details, but adequate for a simple read.
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?
Two concise sentences: first conveys core purpose and format, second adds demo info and sibling guidance. 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?
For a simple documentation reader with one parameter and no output schema, the description sufficiently covers input and output behavior. Minor omission: no mention of error states. Overall complete enough for typical use.
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 covers the only parameter (path) with already a clear description. The description adds practical guidance: 'Remember to include the component prefix if you extracted it from a grouped list', which adds value beyond the schema.
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?
Description clearly states verb ('reads') and resource ('Kendo UI documentation article') and adds format ('Markdown') and included demos. Distinguishes from sibling read_demo_source.
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?
Explicitly names a sibling alternative (read_demo_source) for when demo source code is needed. Lacks explicit when-not conditions for other siblings, but the purpose is specific enough.
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.
v1.0.3list_component_apilist_component_topicslist_kendo_componentsread_demo_sourceread_kendo_docScored across 5 tools
Each tool has a clearly distinct purpose: listing all components, retrieving API details, fetching topics/ articles, reading documentation articles, and fetching demo source code. The description of list_component_topics explicitly directs users to list_component_api for deep API references, preventing confusion.
All tools follow a consistent verb_noun pattern: list_, read_. The names are descriptive and predictable, making it easy to infer functionality.
With 5 tools, the server is well-scoped for a documentation API. Each tool covers a necessary operation without being excessive or insufficient.
The tool set covers the full workflow of browsing Kendo UI Angular documentation: discovering components, exploring APIs, reading articles, and examining demo source code. No obvious gaps are present.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Knowledge Network for AI Agents and creators: Search, rate, and review programming guides via MCP
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.