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., "@arkts-knowledge-search What is the difference between @State and @Prop in ArkUI?"
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.
把 DevEco Code 的 arkts_knowledge_search 在线知识查询能力独立为 MCP 服务。
本项目不安装、启动或依赖 DevEco Code，也不包含 @deveco/deveco-cli：
工具名称和 question 参数与 DevEco Code 的 arkts_knowledge_search 保持一致。
在线查询调用华为 bigSearch 服务。
登录使用独立的华为 OAuth 流程。
JWT 加密保存在本机，短期 accessToken 只存在于进程内存，不会写入日志或 MCP 返回值。
MCP 配置：
{
"mcpServers": {
"arkts-knowledge-search": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@rvaim/arkts_knowledge_search"
]
}
}
}命令行：
# 检查登录状态
npx -y @rvaim/arkts_knowledge_search status
# 登录，只打开华为官方页面
npx -y @rvaim/arkts_knowledge_search login
# 查询在线知识
npx -y @rvaim/arkts_knowledge_search search "UIAbility onCreate 的调用顺序"Related MCP server: OAuth MCP Server
工具 | 用途 |
| 查询 ArkTS、ArkUI、HarmonyOS 与 OpenHarmony 在线知识 |
| 检查在线登录状态 |
| 打开华为官方 OAuth 页面登录 |
| 清理本 MCP 保存的加密登录凭据 |
arkts_knowledge_search 接收一个 question 字符串。问题应简洁，并包含 API、装饰器、生命周期名称、构建错误或现象等关键信息。
在线登录使用：
https://cn.devecostudio.huawei.com登录凭据默认保存在：
~/.config/arkts-knowledge-search/可通过 ARKTS_KNOWLEDGE_SEARCH_DATA_DIR 修改目录。凭据使用 AES-256-GCM 加密，凭据文件与密钥文件权限设为当前用户可读写。
macOS 如需指定登录浏览器：
ARKTS_KNOWLEDGE_BROWSER="Google Chrome" npx -y @rvaim/arkts_knowledge_search login当前登录仅支持中国站华为账号。在线接口属于华为服务，可能独立于本项目更新。
本包只负责在线知识查询。@deveco/deveco-cli 的本地文档、构建、运行、设备、模拟器和日志能力应由 AI 插件独立配置，不作为本包依赖。
本项目采用 MIT 许可证。派生来源与第三方声明见 THIRD-PARTY-NOTICES.md。
打开华为官方登录页面，完成在线知识查询 OAuth 登录。不会安装或启动 DevEco Code。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (openWorldHint=true, readOnlyHint=false, destructiveHint=false) are consistent and description adds value: clarifies it opens webpage and completes OAuth, explicitly states no installation or launch of DevEco Code, which is beyond 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 concise sentences with no wasted words. Main action is front-loaded.
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 zero parameters and no output schema, the description covers the essential: action, scope, and negative clarification. Could add a note on success/failure indication but is sufficiently 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?
No parameters, schema coverage 100%. Baseline for 0 params is 4. Description does not need to add parameter info and appropriately focuses on purpose.
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 uses specific verbs '打开' and '完成' and identifies the resource as '华为官方登录页面' for online knowledge query OAuth login. It clearly distinguishes from siblings (logout, search, status) by being the authentication step.
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?
No explicit guidance on when to use or alternatives. Implication is clear (use when login is needed) but no direct mention of prerequisites or context relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除本 MCP 在本机保存的加密登录凭据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds that it deletes 'encrypted login credentials' saved locally, providing specific context beyond 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?
Single sentence concisely captures the action with no unnecessary words.
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 simple parameterless logout tool with no output schema, the description fully explains the action and outcome.
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?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter info, baseline 4 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?
Description clearly states it deletes locally saved encrypted login credentials, which is the logout action. It distinguishes from siblings (login, search, status) by specifying the credential deletion action.
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?
Implicitly used after login to log out, but no explicit guidance on when to use or alternatives. Since it's a simple action, this is adequate but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询 ArkTS、ArkUI、HarmonyOS 与 OpenHarmony 在线知识库。适用于 .ets 代码、装饰器、生命周期、状态刷新、SDK API、DevEco 或 hvigor 构建错误，以及 @kit.、@ohos. API。
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | 简洁的问题，应包含关键符号、API、装饰器、生命周期名称、构建错误或现象。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context about the knowledge base and suitable topics but does not disclose additional behavioral traits like response format, pagination, or rate limits.
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 two sentences, front-loaded with the core purpose and followed by a specific applicability list. Every word is purposeful with no 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?
For a simple single-parameter search tool with annotations indicating read-only and open-world, the description covers what is queried and applicable topics. It could mention return format but is otherwise 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?
Schema coverage is 100% with a detailed property description. The tool description reiterates similar guidance but adds minimal new meaning beyond the schema. Baseline 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 it queries an online knowledge base for ArkTS, ArkUI, HarmonyOS, and OpenHarmony, listing specific use cases like .ets code, decorators, lifecycle, etc. It implicitly distinguishes from sibling tools (login, status, logout) which serve different purposes.
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 that the tool is for querying knowledge about specified topics, but it does not explicitly state when not to use it or offer alternatives. The sibling tools are unrelated, so usage is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查在线知识查询登录状态，不返回任何令牌。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that no token is returned, which is a useful behavioral detail beyond what annotations provide.
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?
Single sentence, zero waste, perfectly concise.
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 status-check tool, the description combined with annotations provides adequate context. However, it could be improved by specifying the expected return value (e.g., true/false).
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?
No parameters exist, so baseline 4. Description does not need to add parameter info.
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 checks the login status for online knowledge queries, and it is distinct from siblings (login, logout, 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?
No guidance is given on when to use this tool vs alternatives. It is implied that one might check status before using search, but not explicit.
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. Dates show when Glama detected each change.
v0.1.0arkts_knowledge_loginarkts_knowledge_logoutarkts_knowledge_searcharkts_knowledge_statusEach tool has a clearly distinct purpose: login, logout, status check, and search. No overlap or ambiguity.
All tools share a common 'arkts_knowledge_' prefix and use imperative verb names except 'status', which is a noun. Nearly consistent.
Four tools is well-scoped for authentication and knowledge search—neither too few nor too many.
The set covers the full authentication lifecycle (login, logout, status) and the core search operation. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rvaim/arkts-knowledge-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
