ArkUIBuilder MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ARKUIBUILDER_MY_WIDGETS | No | Path of the plugin's my-widgets.json (used to list My Widgets saved with the ArkUIBuilder IDE plugin) | |
| ARKUIBUILDER_CATALOG_FILE | No | Read the catalog from a saved getWidgetCatalog response instead of the network |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_widgetsA | Search ready-made HarmonyOS ArkUI components (ArkUIBuilder catalog plus the user's My Widgets). Each result shows the call to write in build() and its required parameters. Call with no arguments for an overview of platforms and categories. |
| get_widgetA | Details of one widget by component name (e.g. ColorStudioFb), id or title. Set include_code only if you need to read or adapt its source; to use it as-is call add_widget instead. |
| add_widgetA | Copies a widget's component into /src/main/ets/components/.ets and adds its import to target_file. Returns the call to place in build(). Never overwrites a different existing file unless overwrite is true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
search_widgets (discover), get_widget (inspect source/details), and add_widget (install into module) have distinct actions, and the descriptions explicitly steer between them (e.g. 'to use it as-is call add_widget instead'). There is mild overlap since search results already return the build() call and parameters, making get_widget's unique value narrower, but the boundaries are clearly drawn.
All three tools follow a clean verb_noun snake_case pattern: search_widgets, get_widget, add_widget. The convention is predictable and consistent throughout.
Three tools is on the thin side, but the server's scope (search a widget catalog, inspect a widget, install it) is genuinely narrow, so each tool earns its place. A list-categories or remove-widget tool would round it out but the count is reasonable for the purpose.
The core lifecycle of discover -> inspect -> install is fully covered, including an overview mode (search with no args) and a copy/install operation. Minor gaps exist (no tool to remove or update an already-installed widget), but these are workarounds an agent can handle manually.