ArkTS Helper MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 4.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![arkts-helper MCP server](https://glama.ai/mcp/servers/LongLiveY96/arkts-helper/badges/card.svg)](https://glama.ai/mcp/servers/LongLiveY96/arkts-helper)

Score Badge

Copy to your README.md:

[![arkts-helper MCP server](https://glama.ai/mcp/servers/LongLiveY96/arkts-helper/badges/score.svg)](https://glama.ai/mcp/servers/LongLiveY96/arkts-helper)

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