wechat-devtools-mcp

Overview Schema Source Related Servers Discussions Admin

wechat_automator

Automate WeChat mini-program testing by performing UI actions, invoking methods, mocking APIs, evaluating JS, and querying page, system, and storage data.

Instructions

小程序自动化交互与运行时查询。支持 action: start(开启自动化), tap(点击), input(输入), element_info(元素信息), set_data(设置数据), call_method(调用方法), call_wx(调用wx API), mock_wx(Mock wx), evaluate(执行JS), page_stack(页面栈), page_data(页面数据), system_info(系统信息), storage(缓存)。返回 JSON: {success, data, message, error_code?}。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.9.18Sep 8, 2026

changedInput schema / $defs / WechatAutomatorInput / properties / args_json / description

Previous value: -"方法参数 JSON 数组，call_method/call_wx 时可选。"New value: +"JSON 数组，call_method/call_wx 的方法参数，或 evaluate(fn_source) 的函数入参；可选。"

changedInput schema / $defs / WechatAutomatorInput / properties / expression / description

Previous value: -"JS 表达式，evaluate 时必填。"New value: +"单个 JS 表达式，evaluate 时使用；多语句请改用 fn_source。"

addedInput schema / $defs / WechatAutomatorInput / properties / fn_source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "evaluate 时可用：完整函数源码字符串，例如 'function(){ return wx.getSystemInfoSync(); }' 或 '(a,b)=>a+b'，在小程序 AppService 内以 page.evaluate(fn, ...args) 方式执行，入参来自 args_json。函数体可含任意多条语句，需显式 return。与 expression 二选一，同时给则以 fn_source 为准。",
+  "title": "Fn Source"
+}

First observedv0.9.16Sep 1, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations are all false (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the burden of behavioral disclosure. It does disclose the return format (JSON with success, data, message, error_code?) which adds real value. However, it never warns about the side effects of mutating actions (tap, input, set_data, mock_wx) or states prerequisites such as needing to call start before other actions. No contradiction with annotations.

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 compact and front-loaded with the purpose statement, followed by a tight list of action annotations and the return format. Each action is one short line. It is appropriately concise for a multi-action dispatcher, though the long enumeration is inherent to the tool's design.

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

Completeness3/5

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

For a complex 13-action, 14-parameter tool, the description lists every action and the output schema, but omits operational sequencing (e.g., start must precede other actions), environment/connection requirements (device or IDE link), and error-handling behavior beyond the error_code field. The output schema presence mitigates the return-value gap, but an agent still lacks enough context to drive the tool through a real workflow.

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?

The schema provides detailed descriptions for all 14 parameters (selector requirements, fn_source execution semantics, data_json for set_data, etc.), so the schema carries the heavy lifting and the baseline is 3. The description itself adds minimal parameter meaning beyond listing action names; it does not compensate for anything since the schema is already thorough.

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 states a specific purpose — WeChat mini-program automation interaction and runtime querying (小程序自动化交互与运行时查询) — and enumerates all 13 supported action modes. The verb+resource combination is clear and comprehensive, but it does not explicitly distinguish itself from the sibling tools (build, file, ide, inspector, navigate, screenshot), so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists actions and the per-param required conditions live in the schema (e.g., 'selector: tap/input/element_info 时必填'), but the description itself provides no guidance on when to use this tool versus alternatives, no use-case scenarios, and no exclusions. An agent gets no help deciding between this and wechat_inspector or wechat_navigate.

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

Deploy Server