Which integrations are available for this server?

Provides documentation search and AI Q&A for ArkTS/ArkUI development using Huawei's official documentation and intelligent Q&A service.

How do I use ArkTS Helper MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ArkTS Helper MCP Explain @State vs @Prop in ArkTS" 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.

ArkTS Helper MCP

by LongLiveY96

Overview Schema Related Servers Score Discussions

JavaScript

Remote

ArkTS Helper MCP

ArkTS/ArkUI 开发助手 MCP Server，为 AI 编程助手（Claude Code、Cursor、Windsurf 等）提供文档检索和华为官方智能问答能力。

功能概览

工具	功能	说明
`find_docs`	文档搜索	关键词搜索 1000+ 篇 ArkTS/ArkUI 官方文档
`read_doc`	文档阅读	根据 objectId 获取完整 Markdown 内容
`list_doc_topics`	分类浏览	列出所有文档主题及数量
`ask_ai`	AI 问答	调用华为官方智能问答，获取整合回答
`ask_ai_batch`	批量问答	并行处理多个问题，大幅节省时间
`read_more`	读取全文	获取被截断的完整回答
`set_ai_auth`	设置凭证	配置登录态 Cookie，突破匿名次数限制

Related MCP server: DevDocs MCP Server

快速开始

安装

git clone https://github.com/LongLiveY96/arkts-helper-mcp.git
cd arkts-helper-mcp
npm install
npm run build

配置 AI 助手

Claude Code / Cursor / Windsurf：

{
  "mcpServers": {
    "arkts-helper": {
      "command": "node",
      "args": ["/path/to/arkts-helper-mcp/dist/index.js"]
    }
  }
}

HTTP 模式（可选）

npm run start:http

端点：

GET /health — 健康检查
GET /search?q=关键词 — 搜索文档
GET /doc/:objectId — 获取文档
GET /topics — 列出主题

使用示例

配置完成后，AI 助手会自动调用工具：

用户：@State 和 @Prop 有什么区别？
AI：→ find_docs({ query: "State Prop 装饰器" })
    → read_doc({ objectId: "arkts-state" })
    @State 是组件私有状态，@Prop 是单向数据传递...

用户：Navigation 怎么实现页面跳转并传参？
AI：→ ask_ai({ query: "Navigation 页面跳转传参" })
    Navigation 是路由容器组件，通过 NavPathStack 管理页面栈...

用户：同时告诉我 @State、@Prop、@Link 的用法
AI：→ ask_ai_batch({ queries: ["@State用法", "@Prop用法", "@Link用法"] })
    (并行查询，约 60 秒返回全部结果)

环境变量

变量名	说明	默认值
`ARKTS_DOCS_DIR`	文档目录路径	`static/docs`
`ARKTS_MCP_PORT`	HTTP 服务端口	`3456`
`ARKTS_QA_TIMEOUT_MS`	AI 问答超时（毫秒）	`120000`
`ARKTS_MCP_CONFIG_DIR`	Cookie 配置目录	`~/.config/arkts-mcp`

AI 问答认证（可选）

匿名模式有次数限制。配置登录态 Cookie 可解除限制：

登录 developer.huawei.com
F12 → Network → 使用智能问答提问
找到 dialog/submission 请求，复制 Cookie
通过工具设置：set_ai_auth({ cookie: "你的Cookie" })

Cookie 保存在 ~/.config/arkts-mcp/config.json，不会进入代码仓库。

许可证

MIT

Available Tools

7 tools

ask_aiA

向华为开发者官方智能问答助手提问。

使用场景

当需要获取更全面、更权威的鸿蒙开发答案时使用此工具：

复杂的开发问题（整合了官方文档 + 社区经验）
需要代码示例和最佳实践
错误排查和问题解决
获取最新的开发建议

与 find_docs 的区别

find_docs：搜索本地文档，返回原始文档内容
ask_ai：调用华为官方 AI，返回整合后的智能回答

使用示例

示例1 - 用户问："Navigation 怎么实现页面跳转并传参？" 调用：ask_ai({ query: "Navigation 怎么实现页面跳转并传参" })

示例2 - 用户问："List 组件性能优化有哪些方法？" 调用：ask_ai({ query: "List 组件性能优化方法" })

返回华为官方智能助手的回答，包含参考链接。

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要问的问题，使用中文效果更好
`newSession`	No	是否开启新会话（默认 false，复用之前的会话上下文）

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description discloses it calls Huawei official AI, returns integrated answer with reference links. Lacks potential limitations like network dependency or latency, but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections for usage, comparison, and examples. Each part adds value, though slightly verbose; front-loaded.

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?

Tool complexity moderate; no output schema but describes return type. Examples provided. Could mention error scenarios or query constraints, but adequate.

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 coverage is 100% with detailed descriptions. Description adds only minor extra context (Chinese language hint) and examples, meeting baseline.

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?

Description clearly states '向华为开发者官方智能问答助手提问' (ask Huawei developer official AI Q&A assistant), specifies it returns integrated answers, and distinguishes from sibling tool find_docs.

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?

Explicitly lists when to use (complex problems, code examples, error troubleshooting, latest advice) and provides comparison with find_docs, plus examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ask_ai_batchA

批量向华为开发者官方智能问答助手提问（并行处理）。

使用场景

当需要同时查询多个问题时使用此工具：

一次调用处理多个相关问题
服务器端并行执行，大幅节省时间
适用于需要查询多个不同主题的场景

与 ask_ai 的区别

ask_ai：单次提问，多个问题需要多次调用
ask_ai_batch：批量提问，一次调用处理多个问题（并行执行）

使用示例

示例1 - 批量查询不同主题：调用：ask_ai_batch({ queries: ["Navigation 组件用法", "List 性能优化", "@State 和 @Prop 区别"] })

示例2 - 批量查询相关问题：调用：ask_ai_batch({ queries: ["如何实现页面跳转", "如何传递参数", "如何返回数据"] })

性能优势

假设单个问题响应时间 60 秒：

串行调用 3 个问题：60s + 60s + 60s = 180 秒
批量并行调用：约 60 秒（取决于最慢的问题）

ParametersJSON Schema

Name	Required	Description	Default
`queries`	Yes	问题列表，支持中英文。例如：["Navigation 组件用法", "List 性能优化"]
`newSession`	No	是否开启新会话（默认 false，复用之前的会话上下文）

TDQS

A4.7/5.0

Behavior4/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 parallel execution, session reuse via newSession parameter, and performance comparison. However, it does not mention error handling or rate limits, which would be beneficial.

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 well-structured with clear sections (使用场景, 区别, 示例, 性能优势). Every sentence provides useful information; no fluff. The performance comparison is especially helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters and no output schema, the description covers usage, alternatives, examples, and performance expectations. It is complete enough for an agent to invoke correctly without ambiguity.

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?

Schema coverage is 100%, but the description adds value by providing concrete examples for the queries parameter and explaining the newSession parameter's role in session context. This goes beyond 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 it is for batch querying the Huawei developer AI assistant in parallel. It explicitly distinguishes from sibling tool ask_ai by describing batch vs single query behavior.

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 provides a dedicated '使用场景' section explaining when to use, contrasts with ask_ai, and gives multiple usage examples. It explicitly states server-side parallel execution and time savings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_docsA

搜索 HarmonyOS ArkTS 官方开发文档。

使用场景

当用户询问以下内容时，应主动使用此工具搜索相关文档：

ArkTS 语法特性和语言约束
ArkUI 组件用法（Button、Text、Column、Row、List、Grid 等）
状态管理装饰器（@State、@Prop、@Link、@Observed、@ObjectLink 等）
动画和转场效果（animateTo、transition、共享元素转场等）
导航和路由（Navigation、NavDestination、Router 等）
系统能力和 API（文件访问、网络请求、数据存储等）
错误码和问题排查

使用示例

示例1 - 用户问："@State 和 @Prop 有什么区别？" 调用：search_arkts_docs({ query: "State Prop 装饰器" })

示例2 - 用户问："怎么实现页面跳转？" 调用：search_arkts_docs({ query: "Navigation 路由页面跳转" })

示例3 - 用户问："List 组件怎么用？" 调用：search_arkts_docs({ query: "List 列表组件" })

示例4 - 用户问："动画怎么实现？" 调用：search_arkts_docs({ query: "animateTo 属性动画" })

搜索技巧

使用中文关键词效果更好
可以组合多个关键词，用空格分隔
搜索组件时加上"组件"后缀，如"Button组件"
搜索装饰器时可以带@符号，如"@State"

返回匹配的文档列表，包含标题、预览和 objectId（用于 read_doc 获取完整内容）。

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	搜索关键词，支持中英文，多个关键词用空格分隔。例如："State管理"、"Button组件"、"Navigation路由"、"动画转场"
`limit`	No	返回结果数量，默认10条，最多50条

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It details the return format (title, preview, objectId) and suggests search keyword behavior (e.g., Chinese keywords work better). It does not mention side effects or safety, but as a search tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and examples, but is somewhat lengthy. However, every section adds value, so it earns a score of 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return content, parameters are fully covered, and the workflow with read_doc is hinted. This makes the tool self-contained for effective use.

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?

Schema coverage is 100% with descriptions for both parameters. The description adds significant value by providing example usage and search tips, enriching the understanding beyond the schema.

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 it searches HarmonyOS ArkTS official documentation, and the usage scenarios differentiate it from sibling tools like list_doc_topics and read_doc, making the purpose unambiguous.

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 explicitly lists when to use the tool (various ArkTS-related queries) and provides search tips. It references read_doc for obtaining full content, implying a workflow. However, it does not explicitly state when not to use it or compare to list_doc_topics, slightly reducing clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_doc_topicsA

列出 ArkTS 文档的所有主题分类。

使用场景

了解文档库的整体结构
查看有哪些主题分类
统计各分类的文档数量

使用示例

当用户问"文档有哪些分类？"或"有什么类型的文档？"时调用此工具。

返回所有主题分类及其文档数量。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/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. It states that the tool returns categories and counts, but does not explicitly disclose whether it is read-only, requires auth, or has any side effects. It adequately describes the output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for purpose, usage scenarios, and an example. It is concise and front-loaded with the primary function. However, the use of Chinese may slightly reduce clarity for English-only agents.

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?

For a simple parameterless tool, the description covers the purpose, usage context, and return format. It is complete enough given the low complexity and absence of output schema.

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?

There are no parameters, and schema coverage is 100%. Per rules, baseline 4 is appropriate; the description does not need to add parameter information.

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 that the tool lists all topic categories of ArkTS documents with document counts. It is distinct from sibling tools like find_docs or read_doc, which are for searching or reading content.

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 explicit usage scenarios (understanding structure, viewing categories) and an example query, guiding when to use this tool. It does not specify when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_docA

读取 ArkTS 文档的完整内容。

使用场景

在使用 find_docs 搜索后，根据返回的 objectId 读取文档的完整 Markdown 内容。

使用流程

先调用 find_docs 搜索相关文档
从搜索结果中选择最相关的文档
使用该文档的 objectId 调用此工具获取完整内容

使用示例

示例 - 搜索后读取完整文档：

调用：find_docs({ query: "State装饰器" })
从结果中找到 objectId: "arkts-state"
调用：read_doc({ objectId: "arkts-state" })

返回文档的完整 Markdown 内容，包含代码示例和详细说明。

ParametersJSON Schema

Name	Required	Description	Default
`objectId`	Yes	文档的唯一标识符，从 find_docs 的搜索结果中获取

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

描述说明返回结果是完整 Markdown 内容且包含代码示例，但未额外披露只读性、权限要求或失败情况。由于无注释，描述承担披露责任，虽然基本行为已明确，但缺乏更深入的行为说明（如是否缓存、是否需要认证），因此评分中等。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

描述使用标题和编号列表结构化呈现，信息密度适中，但部分内容（如使用场景和流程存在重复）可进一步精简，整体上清晰且聚焦。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

工具只有一个参数且无输出 schema，描述提供了完整的上下文：使用前导、流程、示例以及返回内容的基本说明，足以让 AI agent 正确选择和调用。

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?

参数 objectId 的 schema 描述已明确其来源（从 find_docs 获取），描述中重复了该信息但未增加额外语义，如格式或限制。由于 schema 覆盖率为 100%，描述未产生额外价值，基准 3 分合理。

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?

描述明确指定动词'读取'和资源'ArkTS 文档的完整内容'，并通过使用场景与 find_docs 区分，说明该工具用于获取已找到文档的完整内容，与其他兄弟工具（如 find_docs 搜索、ask_ai 问答）界限清晰。

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?

描述详细说明了使用前提（先调用 find_docs）和完整流程（三步），并提供了具体示例，明确指导 AI agent 何时以及如何使用该工具，避免误用。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_moreA

读取被截断的完整回答内容。

使用场景

当 ask_ai 返回的内容被截断时，使用此工具读取完整内容。

使用流程

调用 ask_ai 获取回答
如果回答中包含 "内容过长已缓存" 的提示和 resourceId
使用该 resourceId 调用此工具读取完整内容

使用示例

read_more({ resourceId: "qa-result-1-1706123456789" })

返回完整的 Markdown 格式回答内容。

ParametersJSON Schema

Name	Required	Description	Default
`resourceId`	Yes	资源 ID，从 ask_ai 的回答中获取

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states that the tool returns full Markdown content and requires a resourceId. It does not mention safety or idempotency, but the behavioral implications are clear. No annotations provided.

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 well-organized with sections for usage scenario, flow, and example. It is concise with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one required parameter), the description covers prerequisite, input, and output format (Markdown). It is fully sufficient 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for resourceId. The description adds an example and context on how to obtain the resourceId from ask_ai, enhancing understanding.

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 tool's purpose: to read truncated full responses from ask_ai. It distinguishes from sibling tools like ask_ai, which generates the truncated content.

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?

Explicitly describes when to use (when ask_ai returns truncated content with a resourceId) and provides a usage flow and example. No alternative is needed as it is a complementary tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_ai_authA

设置 AI 问答的登录凭证，用于突破匿名态的次数限制。

使用场景

当 ask_ai 提示次数限制或需要登录时，使用此工具设置登录凭证。

打开浏览器，登录 developer.huawei.com
打开开发者工具 (F12) → Network 标签
在页面上使用智能问答功能提问
找到 dialog/submission 请求
复制 Request Headers 中的 Cookie 值

使用示例

set_ai_auth({ cookie: "your_full_cookie_value_here" })

设置成功后，后续的 ask_ai 调用将使用登录态，无次数限制。

ParametersJSON Schema

Name	Required	Description	Default
`cookie`	Yes	完整的 Cookie 字符串，从浏览器开发者工具中复制

TDQS

A4.2/5.0

Behavior3/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. It explains that setting credentials enables subsequent ask_ai calls to use login and removes limits, but does not disclose behavior for invalid cookies, error handling, or whether previous credentials are overwritten.

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 well-structured with clear sections (usage scenario, how to get cookie, example). It is concise and front-loads the purpose, with no wasted sentences.

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?

For a simple one-parameter tool with no output schema, the description covers purpose, usage, and effect adequately. It could mention the return value or success indication, but overall it is complete enough for effective use.

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 schema already describes the cookie parameter and has 100% coverage, but the description adds significant value by explaining how to extract the cookie from browser developer tools, which goes beyond the schema's definition.

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 tool's purpose: setting AI Q&A login credentials to bypass anonymous usage limits. It uses a specific verb (设置) and resource (登录凭证), and distinguishes itself from sibling tools like ask_ai which require authentication.

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 explicitly states when to use this tool (when ask_ai prompts limit or needs login) and provides a step-by-step guide on how to obtain the cookie. However, it does not mention when not to use it or alternative approaches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jun 18, 2026
- First observedask_ai
- First observedask_ai_batch
- First observedfind_docs
- First observedlist_doc_topics
- First observedread_doc
- First observedread_more
- First observedset_ai_auth

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: ask_ai vs ask_ai_batch are differentiated by single vs batch, find_docs vs read_doc vs list_doc_topics cover different phases of documentation access, read_more handles truncation, and set_ai_auth manages authentication. Descriptions explicitly contrast overlapping tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., ask_ai, find_docs, list_doc_topics). No mixing of conventions like camelCase or inconsistent verb styles.

Tool Count5/5

With 7 tools, the server is well-scoped for its purpose of providing ArkTS documentation search/reading and AI Q&A. Each tool earns its place without redundancy or excessive numbers.

Completeness4/5

The tool surface covers the core workflow: search docs, list topics, read docs, ask AI (single/batch), retrieve truncated responses, and set auth. A minor gap is no explicit tool for clearing auth or browsing AI history, but the set is largely complete for its stated domain.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32
ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,164
renCosta2025-context7fork
ai.smithery
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Documentation Access Developer Tools Search
2

Related MCP Servers

UseKeen Documentation MCP
Documentation Access Search
PromptMixerDev
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search documentation of packages and services to find implementation details, examples, and specifications.
Updated a year ago (2025-05-08 02:00 UTC)
MIT
DevDocs MCP Server
Documentation Access Developer Tools Search
JavierDevCol
F
license
A
quality
D
maintenance
Provides AI models with direct access to documentation for over 600 technologies from DevDocs.io, including popular languages, frameworks, and tools. It enables comprehensive searching, content retrieval, and offline access via an intelligent local caching system.
Updated 8 months ago (2026-01-14 06:37 UTC)
12
2
-
doc-hub-mcp
Documentation Access Search
wxkingstar
F
license
Not graded
quality
C
maintenance
Provides retrieval of WeChat Work and Feishu developer documentation, enabling AI assistants to query API references without switching browsers.
Updated 6 months ago (2026-02-28 06:27 UTC)
18
19
-
ohos-mcp-unofficial
Documentation Access Search
megaacheyounes
F
license
A
quality
D
maintenance
Brings HarmonyOS and OpenHarmony English documentation to AI assistants for instant retrieval and multimodal analysis.
Updated 4 months ago (2026-05-01 16:51 UTC)
3
3
-

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/LongLiveY96/arkts-helper'

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

ArkTS Helper MCP

功能概览

快速开始

安装

配置 AI 助手

HTTP 模式（可选）

使用示例

环境变量

AI 问答认证（可选）

许可证

Available Tools

使用场景

与 find_docs 的区别

使用示例

使用场景

与 ask_ai 的区别

使用示例

性能优势

使用场景

使用示例

搜索技巧

使用场景

使用示例

使用场景

使用流程

使用示例

使用场景

使用流程

使用示例

使用场景

如何获取 Cookie

使用示例

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API