This server provides access to Ionic Framework documentation and related content for AI assistants.
Search documentation: Use search_docs to search official Ionic Framework docs by keyword, with optional filters for section (components, Angular, React, Vue, theming, guides, updating, CLI) and version (v9 or v8).
Read full doc pages: Use get_doc_page with a URL or path to retrieve complete page markdown, including component API references (properties, events, methods, CSS custom properties, shadow parts, slots).
List components: Use list_components to discover Ionic UI components, filter by keyword, and get their tag names and documentation URLs.
Get usage examples: Use get_component_usage to fetch official code examples for a component in Angular, React, Vue, or vanilla JavaScript.
List blog posts: Use list_blog_posts to get the 10 most recent posts from the official Ionic blog, covering releases, announcements, and deprecations for Ionic Framework and Capacitor.
Provides access to Ionic Framework documentation, including component API references, usage examples for Angular, React, Vue, and vanilla JavaScript, and recent Ionic blog posts.
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., "@Ionic Framework MCP Server Show me how to use the Ionic toast component in React"
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.
Unofficial MCP server for the official Ionic Framework documentation. It gives AI assistants the current documentation for Ionic Framework v9 and v8 — including the component API reference and the usage examples for Angular, React, Vue and vanilla JavaScript — plus the Ionic blog. Not affiliated with or endorsed by Ionic or OutSystems.
Maintained by Capawesome.
The server is hosted and ready to use. No account, no token, no installation:
https://ionic-framework-mcp.capawesome.io/mcpRelated MCP server: Angular MCP Server
claude mcp add --transport http ionic-framework https://ionic-framework-mcp.capawesome.io/mcpGo to Settings → Connectors → Add custom connector and enter:
Name: Ionic Framework
URL: https://ionic-framework-mcp.capawesome.io/mcp
Or add .cursor/mcp.json to your project:
{
"mcpServers": {
"ionic-framework": {
"url": "https://ionic-framework-mcp.capawesome.io/mcp"
}
}
}Or add .vscode/mcp.json to your project:
{
"servers": {
"ionic-framework": {
"type": "http",
"url": "https://ionic-framework-mcp.capawesome.io/mcp"
}
}
}Add the server to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"ionic-framework": {
"serverUrl": "https://ionic-framework-mcp.capawesome.io/mcp"
}
}
}Add the server to your Zed settings.json:
{
"context_servers": {
"ionic-framework": {
"url": "https://ionic-framework-mcp.capawesome.io/mcp"
}
}
}Clients that cannot connect to a remote server over HTTP can run this package, which proxies stdio to the hosted server:
{
"mcpServers": {
"ionic-framework": {
"command": "npx",
"args": ["-y", "@capawesome/ionic-framework-mcp"]
}
}
}Requires Node.js 22 or later.
Tool | Purpose | Parameters |
| Search the documentation by keyword. Start here for any Ionic Framework question. |
|
| Read a full documentation page returned by |
|
| List Ionic Framework components with their API reference. |
|
| Read usage examples for a component, per framework. |
|
| List recent posts from the Ionic blog. | — |
The documentation is available for Ionic Framework v9 (default) and v8. Pass the version parameter to target a specific version.
The endpoint is limited to 100 requests per minute per IP. Requests over the limit are answered with 429 Too Many Requests; retry after a short wait.
Your IP address is processed for rate limiting only. Queries and tool arguments are not stored, not logged beyond Cloudflare's standard edge logs, and never used for training. See the Privacy Policy for details.
Capacitor MCP Server — the same for the Capacitor documentation, plugin list and blog.
Capawesome MCP Server — the official MCP server for the Capawesome documentation and the Capawesome Cloud management API.
Capawesome Cloud Live Updates — ship JavaScript, HTML and CSS changes to your app without an app store review.
Capawesome Cloud Native Builds — build native iOS and Android apps in the cloud, without a Mac.
Capawesome Cloud App Store Publishing — submit builds to the Apple App Store and Google Play Store.
The documentation content is © the Ionic team, licensed under Apache-2.0 and sourced from ionic-team/ionic-docs. It is converted from MDX to Markdown for delivery over MCP and otherwise served unmodified in substance. The component API reference comes from the @ionic/docs package (MIT). Blog excerpts come from the Ionic blog and link to the original post.
See NOTICE for the full attribution.
npm install
npm run build
npm testSet IONIC_FRAMEWORK_MCP_URL to point the proxy at a local server instead of the hosted one:
IONIC_FRAMEWORK_MCP_URL=http://localhost:8787/mcp node dist/index.jsReleases are managed by release-please. Merging its release pull request tags the version, publishes the package to npm and then publishes server.json to the MCP Registry. The version in server.json is bumped by release-please together with package.json, so it never has to be edited by hand. To publish to the registry manually, install mcp-publisher, run mcp-publisher login dns --domain=capawesome.io --private-key=<key> with the Ed25519 private key from the password manager and then mcp-publisher publish.
See LICENSE.
Read the official usage examples of one Ionic Framework component, as published on its documentation page. Use this before writing markup for a component to see how it is actually used in Angular, React, Vue or vanilla JavaScript — the template, the component class and the styles that belong together. Call it without an example first to see which examples the component offers. Returns the examples of the component with the frameworks each provides, or, when an example is given, its code per framework as fenced code blocks — one section per framework, and one block per file where an example spans several files. Do not use this for the component's API reference: its properties, events, methods, CSS shadow parts, CSS custom properties and slots are on the documentation page, which get_doc_page returns.
| Name | Required | Description | Default |
|---|---|---|---|
| example | No | The id of one example, e.g. "basic" or the nested "presentation/date". Defaults to listing the examples of the component instead of returning code. Optional. | |
| version | No | Optional. Ionic Framework docs version. Defaults to v9. Match the major version of @ionic/core (or @ionic/angular, @ionic/react, @ionic/vue) in the user's package.json. | |
| component | Yes | The component to read the examples of, e.g. "button". The tag is accepted too, e.g. "ion-button". | |
| framework | No | Optional. The framework to return the example for, e.g. "react". Match the framework of the user's project. Defaults to returning every framework the example provides. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the bar is lower. The description adds useful behavioral details about return types (code per framework, fenced blocks) and default behaviors (version, framework), without contradicting the annotations.
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 well-structured and front-loaded with the main purpose, followed by usage context and return details. While moderately long, it avoids redundancy and every sentence contributes essential 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?
Since there is no output schema, the description thoroughly explains what the tool returns (examples list or code per framework, fenced blocks, per-file sections). It also covers version and framework matching and points to the sibling get_doc_page for API reference, making it complete for an agent to use correctly.
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% and each parameter has a descriptive comment including defaults. The description adds minimal extra meaning beyond the schema, primarily reiterating the example default and usage. It does not significantly deepen understanding of parameter semantics beyond what is already present.
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 reads official usage examples of an Ionic Framework component, specifying the action (read) and resource (usage examples). It also distinguishes itself from siblings by explicitly noting not to use it for API reference, which is handled by get_doc_page.
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?
Provides explicit when-to-use guidance ('Use this before writing markup for a component') and when-not-to-use ('Do not use this for the component's API reference'). It also advises calling without an example first to list available examples, giving clear operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full markdown of a single page of the official Ionic Framework documentation. Use this after search_docs to read a page end to end before writing markup against a component, because search snippets are deliberately short and regularly omit required setup steps. A component page carries the complete API reference of that component: its properties with types and defaults, events, methods, CSS shadow parts, CSS custom properties and slots. Returns the page title, its URL, the documentation version and the complete page markdown including code samples. Do not use this to find a page: it needs an exact URL or path, so run search_docs first. Do not use it for pages outside ionicframework.com — Capacitor and native plugins are covered by the Capacitor MCP server at https://capacitor-mcp.capawesome.io/mcp, Capawesome plugins and Capawesome Cloud by the Capawesome MCP server at https://mcp.capawesome.io/mcp.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL or site-relative path, e.g. "https://ionicframework.com/docs/api/button", "api/button", "angular/navigation" or "v8/api/button". An anchor is ignored; the whole page is returned. | |
| version | No | Optional. Ionic Framework docs version. Defaults to v9. Match the major version of @ionic/core (or @ionic/angular, @ionic/react, @ionic/vue) in the user's package.json. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral details such as ignoring anchors and returning the whole page, plus the version defaulting behavior, which goes beyond just safety.
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 well-structured and front-loaded: it begins with the core action, then usage context, then details about page content and return value, and finally clear exclusions. It is concise but informative, with no fluff 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 schema covers all parameters and there is no output schema, the description provides sufficient context: it mentions the returned fields (title, URL, version, markdown) and clearly scopes the tool to Ionic docs only. It also supplies enough guidance to avoid misuse.
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 already provides thorough descriptions for both parameters, including examples for URL formats, the anchor caveat, version defaults, and matching to package.json. The main description adds no extra semantic value beyond what the schema already covers.
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 reads a full documentation page from the official Ionic Framework docs, specifying the verb 'Read' and the resource. It also distinguishes itself from siblings by explicitly positioning it after search_docs and warning against using it for finding pages.
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 gives explicit when-to-use guidance: use after search_docs to read a page end-to-end before writing markup, and do not use it to find a page because it requires an exact URL. It also excludes Capacitor and external docs, making the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 10 most recent posts from the official Ionic blog, newest first. Use this when the question is about what is new — recent releases, announcements or deprecations. The blog covers both Ionic Framework and Capacitor. Returns title, date, tags, url and excerpt per post. Do not use this to answer a documentation question: the feed only carries the newest posts, so search the documentation with search_docs instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond that: it returns exactly 10 posts, orders them newest first, covers both Ionic Framework and Capacitor, and lists the returned fields. This is strong supplemental behavior disclosure for a simple read-only feed.
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 front-loaded with the primary purpose, then gives usage boundaries and return fields. Every sentence adds value and there is no redundant filler.
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 parameterless read-only tool with a sibling documentation search, the description covers what it returns, when to use it, and the alternative. Nothing necessary for correct invocation is missing.
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?
There are zero parameters, so the schema fully covers parameter semantics. The description doesn't need to add parameter-level detail, and it doesn't. Baseline 4 is appropriate for a no-parameter tool.
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?
States a specific verb and resource: lists the 10 most recent official Ionic blog posts, newest first. It also distinguishes itself from documentation retrieval tools by naming the blog as a separate resource.
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 says when to use it — for news about releases, announcements, or deprecations — and when not to: for documentation questions, it directs the agent to search_docs. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the UI components of Ionic Framework, optionally filtered by a keyword. Use this to find the component that fits a piece of UI before building it by hand, and to learn the custom element name it is used under. Use limit 100 to list every component. Returns tag, description and url per component, where url is the documentation page carrying its full API reference. Do not use this to read a component's API: call get_doc_page with the returned url. Do not use it for Capacitor plugins or native capabilities, which are covered by the Capacitor MCP server at https://capacitor-mcp.capawesome.io/mcp.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of items to return, e.g. 5. Defaults to 25, maximum 100. | |
| query | No | A free-text filter matching the tag or the description, e.g. "modal". Defaults to no filter. Optional. | |
| version | No | Optional. Ionic Framework docs version. Defaults to v9. Match the major version of @ionic/core (or @ionic/angular, @ionic/react, @ionic/vue) in the user's package.json. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict these. It adds useful behavioral context by stating the return shape (`tag`, `description`, `url`) and the default version behavior, giving an agent confidence about side effects and output expectations.
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 well-structured and front-loaded with the core purpose, followed by usage guidance, return format, and exclusions. A few phrases are slightly redundant (e.g., 'Use limit 100 to list every component' restates the schema), but overall every sentence adds useful context and nothing is unclear.
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?
Even without an output schema, the description explicitly names the returned fields, explains the default version, gives a query example, and provides alternative tool routing. This is enough for an agent to invoke the tool correctly and interpret its results without additional context.
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?
All three parameters are fully described in the schema, and the description reinforces each: `limit` is tied to listing every component, `query` is illustrated with 'modal', and `version` is linked to matching the user's package.json. The parameter meanings are clear and actionable beyond the raw 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 a specific action ('List') on a specific resource ('UI components of Ionic Framework') and distinguishes this tool from siblings by explicitly routing API reads to get_doc_page and Capacitor topics elsewhere. This makes the tool's purpose immediately obvious and unambiguous.
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?
It provides explicit when-to-use guidance ('find the component that fits a piece of UI before building it by hand'), when-not-to-use guidance (API reads, Capacitor plugins), and practical tips like using limit 100 to list every component. Sibling alternatives are named directly, so an agent knows exactly when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the official Ionic Framework documentation from ionicframework.com by keyword. Use this first for any question about Ionic Framework itself — a UI component and its properties, events and CSS custom properties, theming and layout, the Angular, React and Vue integrations, navigation and routing, the Ionic CLI, or upgrading to a newer major version — because guessing a component property or a CSS variable produces markup that silently does nothing. Returns the best matching page sections with title, url, snippet, section and version, plus the parentTitle and parentUrl of the page a section belongs to. The same results are attached as structured content. Do not use this to read a whole page (call get_doc_page with a url from these results), for Capacitor core, Capacitor plugins or native iOS and Android configuration (use the Capacitor MCP server at https://capacitor-mcp.capawesome.io/mcp instead), or for Capawesome plugins and Capawesome Cloud services such as Live Updates, Native Builds and App Store Publishing (use the Capawesome MCP server at https://mcp.capawesome.io/mcp instead).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of items to return, e.g. 5. Defaults to 10, maximum 25. | |
| query | Yes | The search terms, e.g. "modal dismiss" or "dark mode css variables". Plain keywords work best; no search operators are supported. | |
| section | No | Restrict the search to one part of the documentation, e.g. "components" for the component reference, "theming" for colors, CSS variables and layout, or "angular" for the Angular integration. Defaults to searching every section. | |
| version | No | Optional. Ionic Framework docs version. Defaults to v9. Match the major version of @ionic/core (or @ionic/angular, @ionic/react, @ionic/vue) in the user's package.json. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the main behavioral traits (safety, non-destructive, open-world) are covered. The description adds the return format ('Returns the best matching page sections with title, url, snippet, section and version, plus the parentTitle and parentUrl') which provides some transparency about output structure, but does not detail internal search behavior, ranking, or error handling. Given the annotations cover safety semantics, a score of 3 is appropriate.
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 concise and well-structured, but it is somewhat long due to the detailed list of covered topics and the three 'do not use' clauses. It front-loads the core purpose and usage guidance, and the clarifications are useful for disambiguating from siblings. It earns a 4 rather than 5 because the enumeration of topics and exclusions, while valuable, could be seen as slightly verbose, though every sentence contributes meaning.
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 rich schema (4 parameters with full descriptions), clear annotations (readOnly, openWorld, non-destructive), and a descriptive output schema, the tool description fully equips an agent to decide when to use it, how to set parameters (including version matching guidance), and what to expect in the response. The description also differentiates from all sibling tools and alternative MCP servers, making the context 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?
The schema already covers 100% of parameters with descriptions, including examples for query ('modal dismiss' or 'dark mode css variables'), the meaning of section (e.g., 'components' for component reference), and the version instruction (match @ionic/core version). The description reinforces the query semantics ('Plain keywords work best; no search operators are supported') but does not add substantial new meaning beyond the schema. With full schema coverage, a baseline score of 3 is appropriate.
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: to search the official Ionic Framework documentation by keyword. It explicitly enumerates the topics covered (UI component properties, events, CSS custom properties, theming, layout, Angular/React/Vue integrations, navigation, routing, Ionic CLI, upgrading) and distinguishes itself from sibling tools by naming get_doc_page, Capacitor MCP server, and Capawesome MCP server as alternatives for different use cases.
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 gives explicit usage guidance: use this tool first for any question about Ionic Framework itself, and provides clear 'do not use' conditions (for reading whole pages, for Capacitor core/plugins/native configuration, for Capawesome plugins/cloud services) with precise alternative tools (get_doc_page, Capacitor MCP, Capawesome MCP). This leaves no ambiguity about when to select this tool over its siblings.
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.
v0.0.1get_component_usageget_doc_pagelist_blog_postslist_componentssearch_docsScored across 5 tools
Each tool has a clearly scoped responsibility: discover components, read usage examples, search docs, read full pages, and fetch blog posts. Descriptions explicitly direct the agent to the correct tool for adjacent tasks, so there is little chance of misselection.
All tool names follow a consistent snake_case verb_noun pattern: list_*, get_*, search_*. The names are predictable and readable, with only minor variation in object naming that does not hurt consistency.
Five tools is a well-scoped size for a documentation-focused MCP server. Each tool earns its place and covers a distinct user need without redundancy or obvious missing pieces.
The tool set covers the full documentation workflow: discovering components, searching documentation, reading full pages with API references, and inspecting framework-specific usage. Search results and component listings provide URLs that feed directly into get_doc_page, so there are no dead ends.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Versioned documentation registry and semantic search for AI tools and coding assistants.
