Qt 5 and Qt 6 framework and product docs: Qt Creator, MCUs, Squish, Coco and more.
Scored across 2 tools
Search locates documentation pages/symbols while read fetches full content of a known page or symbol. The two tools form a clean find-then-fetch pipeline with no overlap.
Both tools use the identical qt_documentation_<verb> pattern with snake_case verbs (search, read). Fully predictable and consistent.
Two tools is on the thin side, but for a documentation-retrieval server, search plus read is a coherent minimal surface that covers the core workflow without redundancy.
Search and read cover the primary lookup-and-verify loop, but there is no way to browse modules/classes or enumerate versions/symbols, which agents may need for discovery-oriented queries.
Read the full content of a specific Qt documentation page, or a single member of it with 'symbol'. Use the filename shown in search results.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Documentation page filename from a search result (e.g. 'signalsandslots.html'), or a module-relative path (e.g. 'qtcore/qobject.html'). | |
| symbol | No | Optional: Return only one member's documentation instead of the whole page. A name (e.g. 'singleShot', 'anchors.fill', 'AlignmentFlag', 'onCompleted') returns every overload and any property of that name; an enum constant or property access function returns its enum or property. An anchor, shown as {#anchor} after each signature (e.g. 'singleShot-5'), returns that block only. An unknown name returns the page's member list. | |
| version | No | Optional: Qt version to read from (e.g., '6.10.0'). Defaults to the latest installed version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safe-read profile, and the description is consistent with it while adding that the whole page content (not a snippet) is returned and that 'symbol' narrows to a member. It does not mention output format, page size, or truncation behavior, so the added behavioral context is modest beyond 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?
Two short sentences, front-loaded with the primary action and immediately followed by the narrowing option. Every clause carries information; nothing is redundant with the title or restates the name.
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 read-only, single-resource fetch with a fully documented schema and no output schema, the definition covers what is fetched and how to narrow it. Only minor gaps remain, such as whether content is returned raw HTML or Markdown and how large pages are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains all three parameters in depth, including symbol fallback behavior and version default. The description's 'Use the filename shown in search results' adds workflow context but little that the schema does not already say, so the baseline 3 applies.
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 ('Read the full content of a specific Qt documentation page') and covers the member-level variant via 'symbol'. It also implicitly separates itself from the sibling by pointing at search results as the source of the filename, so an agent can tell read apart from search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use the filename shown in search results, and add 'symbol' when only one member is wanted. No explicit when-not clause or naming of the sibling alternative, but the workflow ordering (search first, then read its filename) is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call qt_documentation_search when: (a) you're about to claim a signal/slot/property/default exists, (b) the API is in Qt 6.7+ or a non-core module (MQTT, OPC UA, Network Auth, etc), (c) the user used the words 'docs', 'official', 'verify', or 'check'. Skip when: the question is about basic QString/QObject/signal-slot syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query for Qt documentation (e.g., 'Animation', 'QTimer', 'signal slot'). Optional if 'keywords' is provided. | |
| filter | No | Optional: Filter by document type. One of 'all', 'class', 'qml', 'function', 'guide'. Default is 'all'. Note: 'function' returns the class reference page that contains the function; pass the function name as 'symbol' to the read tool to get just that member. For QML, use 'qml'. | |
| intent | No | Optional: Prioritizes (not filters) results by type. One of 'api', 'tutorial', 'guide', 'concept', 'example', 'migration'. 'api'=class reference, 'tutorial'=how-to guides, 'guide'=overviews, 'concept'=explanations, 'example'=code samples, 'migration'=porting guides. | |
| module | No | Optional: Limit search to specific Qt module (e.g., 'qtcore', 'qtwidgets', 'qtqml', 'qtquick', 'qtnetwork') | |
| product | No | Optional: Limit search to a specific documentation product (e.g. 'qt', 'qtcreator', 'pyside6'). Omit to search all products. | |
| version | No | Optional: Qt version to search (e.g., '6.10.0', '6.9.0'). Defaults to latest installed version if not specified. | |
| keywords | No | Optional: Array of keywords to search for. Results match ANY keyword. Example: ["button", "signal", "connect"]. Alternative to 'query' for better multi-term matching. | |
| max_results | No | Optional: Maximum number of results to return (1-10). Default is 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already covered by annotations. The description does not add behavioral details such as result ranking, limits, query-versus-keywords behavior, or what the search returns; its 'Skip when' clause is routing guidance rather than behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact paragraph with front-loaded trigger conditions and no filler. Every clause serves either to route invocation or to exclude an inappropriate case.
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?
The rich schema covers all parameters, and readOnlyHint covers safety, so the description need not repeat those details. However, there is no output schema and the description does not explain the return format or mention following up with qt_documentation_read for full pages, leaving a workflow gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters are already documented in the input schema. The description adds no parameter-level meaning, which is acceptable at the baseline when the schema carries the full burden.
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 makes the tool's verification/search role inferable through concrete triggers such as checking whether a signal/slot/property/default exists and handling Qt 6.7+ or non-core modules. It does not explicitly state 'search Qt documentation' or contrast with the qt_documentation_read sibling, so it is clear but not fully differentiated.
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 gives explicit when-to-use conditions in (a), (b), and (c), plus a clear 'Skip when' exclusion for basic QString/QObject/signal-slot syntax questions. The trigger phrases 'docs', 'official', 'verify', and 'check' make invocation conditions highly actionable.
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.
qt_documentation_read1 field changedInput schema / properties / symbolAdded value: +{
+ "default": "",
+ "description": "Optional: Return only one member's documentation instead of the whole page. A name (e.g. 'singleShot', 'anchors.fill', 'AlignmentFlag', 'onCompleted') returns every overload and any property of that name; an enum constant or property access function returns its enum or property. An anchor, shown as {#anchor} after each signature (e.g. 'singleShot-5'), returns that block only. An unknown name returns the page's member list.",
+ "type": "string"
+}qt_documentation_search1 field changedInput schema / properties / filter / descriptionPrevious value: -"Optional: Filter by document type. One of 'all', 'class', 'qml', 'function', 'guide'. Default is 'all'. Note: 'function' returns the class reference page that contains the function (there are no function-level pages); for QML, use 'qml'."New value: +"Optional: Filter by document type. One of 'all', 'class', 'qml', 'function', 'guide'. Default is 'all'. Note: 'function' returns the class reference page that contains the function; pass the function name as 'symbol' to the read tool to get just that member. For QML, use 'qml'."qt_documentation_read3 fields changedInput schema / properties / file / descriptionPrevious value: -"Filename of the Qt documentation page. Use ONLY the filename from search results (e.g., 'signalsandslots.html' NOT full paths with version numbers). Module paths like 'qtcore/qobject.html' also work."New value: +"Documentation page filename from a search result (e.g. 'signalsandslots.html'), or a module-relative path (e.g. 'qtcore/qobject.html')."Input schema / properties / version / defaultAdded value: +""Input schema / properties / version / descriptionPrevious value: -"Optional: Qt version to read from (e.g., '6.10.0', '6.9.0'). Defaults to latest installed version if not specified."New value: +"Optional: Qt version to read from (e.g., '6.10.0'). Defaults to the latest installed version."qt_documentation_search15 fields changedInput schema / properties / filter / defaultAdded value: +""Input schema / properties / filter / descriptionPrevious value: -"Optional: Filter by document type. Default is 'all'. Note: 'function' returns the class reference page that contains the function (there are no function-level pages); for QML, use 'qml'."New value: +"Optional: Filter by document type. One of 'all', 'class', 'qml', 'function', 'guide'. Default is 'all'. Note: 'function' returns the class reference page that contains the function (there are no function-level pages); for QML, use 'qml'."Input schema / properties / filter / enumRemoved value: -[
- "all",
- "class",
- "qml",
- "function",
- "guide"
-]Input schema / properties / intent / defaultAdded value: +""Input schema / properties / intent / descriptionPrevious value: -"Optional: Prioritizes (not filters) results by type. 'api'=class reference, 'tutorial'=how-to guides, 'guide'=overviews, 'concept'=explanations, 'example'=code samples, 'migration'=porting guides."New value: +"Optional: Prioritizes (not filters) results by type. One of 'api', 'tutorial', 'guide', 'concept', 'example', 'migration'. 'api'=class reference, 'tutorial'=how-to guides, 'guide'=overviews, 'concept'=explanations, 'example'=code samples, 'migration'=porting guides."Input schema / properties / intent / enumRemoved value: -[
- "api",
- "tutorial",
- "guide",
- "concept",
- "example",
- "migration"
-]Input schema / properties / keywords / defaultAdded value: +[]Input schema / properties / max_results / defaultAdded value: +0Input schema / properties / max_results / maximumPrevious value: -10New value: +2147483647Input schema / properties / max_results / minimumPrevious value: -1New value: +-2147483648Input schema / properties / module / defaultAdded value: +""Input schema / properties / product / defaultAdded value: +""Input schema / properties / query / defaultAdded value: +""Input schema / properties / version / defaultAdded value: +""Input schema / requiredAdded value: +[]qt_documentation_search1 field changedInput schema / properties / filter / descriptionPrevious value: -"Optional: Filter by document type. Default is 'all'."New value: +"Optional: Filter by document type. Default is 'all'. Note: 'function' returns the class reference page that contains the function (there are no function-level pages); for QML, use 'qml'."qt_documentation_readqt_documentation_searchRead official Autodesk documentation for 110+ products. No key required.
Apple developer docs and WWDC transcripts with RAG retrieval and Jev relevance ranking.
On-demand access to amCharts 5 docs, code examples, and API reference
MCP server for developers documentation, generated by doc2mcp.
Add one secure layer between your agents and this server.
