基于 FastMCP 的服务器，通过 miniprogram-automator 自动化微信开发者工具。该服务器提供 MCP 工具，让 AI 助手能够导航、检查和操作小程序页面——类似于 playwright-mcp，但专为微信生态系统定制。
微信官方已正式推出「微信开发者工具 Skill」并开启公测，可在 Cursor / Claude 等 AI Agent 环境中直接操作开发者工具：打开项目、编译、模拟器、日志排查、预览上传、云开发等，无需在 IDE 与开发者工具之间反复横跳。
官方维护与版本同步：Skill 随开发者工具 Nightly 发布，与工具能力对齐，不必再维护一套第三方 MCP。
覆盖面更广：不止页面自动化，还包括项目导入、编译构建、真机预览、上传、云环境等。
更贴近真实工作流：Agent 可直接驱动开发者工具完成「写代码 → 编译 → 看模拟器 / 日志 → 预览」闭环。
升级开发者工具
下载 Nightly Electron Build 2.02.2607032 及以上。
安装 Skill（二选一）
命令行（推荐）：终端执行 wechatide，把输出的 Skill 目录交给你的 AI Agent 安装。
图形界面：开发者工具菜单 → 「导出开发者工具 Skill」 → 导入到 Agent。
macOS 上 Skill 常见路径示例：
/Applications/wechatwebdevtools.app/Contents/Resources/app.asar.unpacked/miniprogram-dev-skill调用示例（具体以 wechatide / Skill 文档为准）：
wechatide # 查看 Skill 路径与可用工具
wechatide -c Cursor -t check_devtools_status # 检查登录与环境公测公告：微信开发者工具 Skill 开启公测啦！
场景与使用细节：见公告中的官方文档入口；本地以开发者工具内置 miniprogram-dev-skill 的 SKILL.md 为准。
Related MCP server: weapp-agent-mcp
已安装微信开发者工具，支持命令行访问（cli / cli.bat）
本地已安装 Node.js 18+ 和 npm
有可以在开发者工具中打开的小程序项目
@yfme/weapp-dev-mcp 已发布到 npm，普通使用者无需克隆仓库或手动执行 node dist/index.js。
npx -y @yfme/weapp-dev-mcpnpm install -g @yfme/weapp-dev-mcp
weapp-dev-mcp或作为项目依赖：
npm install --save-dev @yfme/weapp-dev-mcp
npx weapp-dev-mcp只有在本仓库内开发时，才建议直接运行
node dist/index.js。一般用户请按照以上 npm 包方式启动。
要在 Claude Desktop 或其他 MCP 客户端中使用此服务器，请在配置文件中添加：
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": [
"-y",
"@yfme/weapp-dev-mcp"
],
"env": {
"WEAPP_WS_ENDPOINT": "ws://localhost:9420"
}
}
}
}由于使用 Claude Code 调用 MCP 工具时，会触发工具调用权限申请，此时可能会丢失 MCP 与微信开发者工具的连接状态，由于获取控制台输出高度依赖连接状态，此时会无法连贯的获取输出日志，所以建议手动添加权限：
在项目目录下创建 .claude/settings.local.json 文件，或在已有文件添加以下内容后即可免确认直接调用工具，或者根据需要添加您允许免确认调用的工具：
{
"permissions": {
"allow": [
"mcp__weapp-dev-mcp__mp_ensureConnection",
"mcp__weapp-dev-mcp__mp_navigate",
"mcp__weapp-dev-mcp__mp_screenshot",
"mcp__weapp-dev-mcp__mp_callWx",
"mcp__weapp-dev-mcp__mp_mockWxMethod",
"mcp__weapp-dev-mcp__mp_getLogs",
"mcp__weapp-dev-mcp__mp_currentPage",
"mcp__weapp-dev-mcp__mp_listProjects",
"mcp__weapp-dev-mcp__mp_setDefaultProject",
"mcp__weapp-dev-mcp__page_getElement",
"mcp__weapp-dev-mcp__page_getElements",
"mcp__weapp-dev-mcp__page_getElementByXpath",
"mcp__weapp-dev-mcp__page_getElementsByXpath",
"mcp__weapp-dev-mcp__page_waitElement",
"mcp__weapp-dev-mcp__page_waitTimeout",
"mcp__weapp-dev-mcp__page_getData",
"mcp__weapp-dev-mcp__page_setData",
"mcp__weapp-dev-mcp__page_callMethod",
"mcp__weapp-dev-mcp__element_tap",
"mcp__weapp-dev-mcp__element_input",
"mcp__weapp-dev-mcp__element_callMethod",
"mcp__weapp-dev-mcp__element_getData",
"mcp__weapp-dev-mcp__element_setData",
"mcp__weapp-dev-mcp__element_getInnerElement",
"mcp__weapp-dev-mcp__element_getInnerElements",
"mcp__weapp-dev-mcp__element_getWxml",
"mcp__weapp-dev-mcp__element_getStyles",
"mcp__weapp-dev-mcp__element_scrollTo",
"mcp__weapp-dev-mcp__element_getAttributes",
"mcp__weapp-dev-mcp__element_getBoundingClientRect"
]
}
}注意： 工具名称格式为
mcp__<服务器名称>__<工具名称>，请确保服务器名称与您的 MCP 配置中的名称一致。
在使用 MCP 服务器之前，需要先启动微信开发者工具并开启 WebSocket 服务。
💡 在开始之前：
打开微信开发者工具
进入 设置 → 安全设置 → 服务端口
开启 "HTTP 调试" 和 "自动化测试"
使用命令行启动
使用命令行启动微信开发者工具并自动开启 WebSocket 服务：
macOS/Linux：
/Applications/wechatwebdevtools.app/Contents/MacOS/cli auto --project /path/to/your/project --auto-port 9420Windows：
"C:\Program Files (x86)\Tencent\微信web开发者工具\cli.bat" auto --project C:\path\to\your\project --auto-port 9420其中：
--project 参数指定小程序项目目录路径（请替换为实际的项目路径）
--auto-port 参数指定 WebSocket 服务端口（默认 9420）
⚠️ 警告 由于沙箱机制，部分客户端不允许 MCP 访问项目目录以外的微信开发者工具的 cli，所以这里只介绍了使用 WebSocket 服务
通过环境变量控制自动化工具如何连接到微信开发者工具：
变量 | 说明 |
| 【推荐】 已运行的开发者工具 WebSocket 端点。设置后，服务器使用 |
| 微信开发者工具 CLI 路径（如果默认路径有效则可选）。 |
| 强制使用 |
| 启动开发者工具时的首选端口（回退到可用端口）。 |
| 启动超时时间（毫秒，默认 30000）。 |
| 传递给 |
| 启动时传递给 |
| 设置为 |
| 启动时的额外 CLI 参数（空格分隔）。 |
| 传递给开发者工具进程的工作目录。 |
| 设置为 |
| 设为 |
| 启动超时时间（毫秒，默认 45000） |
| 连接超时时间（毫秒，默认 45000） |
| 小程序项目路径（可选） |
注意： 当启动开发者工具（
launch模式）时，必须通过 MCP 工具参数提供小程序项目目录：在执行操作前通过connection.projectPath提供（例如通过mp_ensureConnection）。该值一旦建立，将在后续调用中持久化。
工具调用可以通过 connection 对象覆盖这些默认值中的大部分。
mp_ensureConnection – 确保自动化会话就绪；可选择强制重连或覆盖连接设置
mp_navigate – 在小程序内导航，支持 navigateTo、redirectTo、reLaunch、switchTab 或 navigateBack
mp_screenshot – 捕获屏幕截图并返回（或保存到磁盘）；若微信开发者工具的自动化截图接口失败或超时，请改用客户端/系统提供的截图 API 截取开发者工具模拟器区域
mp_callWx – 调用微信小程序 API 方法（如 wx.showToast）
mp_mockWxMethod – 有限 mock wx 方法能力；当前支持 method: "request"，通过 action: "mock" 设置 wx.request 规则，通过 action: "restore" 恢复原方法
mp_getLogs – 获取小程序控制台日志，可选择获取后清除
mp_currentPage – 获取当前页面信息（路径、查询参数、尺寸、滚动位置），withData 为 true 时额外返回页面数据
mp_listProjects – 列出微信开发者工具中的最近项目，方便选择项目目录
mp_setDefaultProject – 设置默认的小程序项目路径，设置后下次连接会自动使用该项目
page_getElement – 通过选择器获取页面元素，返回元素摘要信息（tagName、text、value、size、offset）；设置 withWxml: true 可额外返回完整 outerWxml；支持 [index=N] 语法选择第 N 个元素
page_getElements – 通过选择器获取页面元素数组，返回每个元素的摘要信息；设置 withWxml: true 可额外返回每个元素的完整 outerWxml；支持 [index=N] 语法
page_getElementByXpath – 通过 XPath 获取页面第一个匹配元素，适合按文本、属性、层级关系、ancestor/following 等表达式定位；设置 withWxml: true 可额外返回完整 outerWxml
page_getElementsByXpath – 通过 XPath 获取页面匹配元素数组，返回每个元素的摘要信息；设置 withWxml: true 可额外返回每个元素的完整 outerWxml
page_waitElement – 等待元素出现在页面上（⚠️ 不适用于自定义组件内部元素）；支持 [index=N] 语法；增加超时和重试间隔参数
page_waitTimeout – 等待指定的毫秒数
page_getData – 获取当前页面的数据对象，可指定路径（支持嵌套路径如 'user.name'）
page_setData – 使用 setData 更新当前页面的数据；增加 verify 选项，验证数据是否真正更新成功
page_callMethod – 调用当前页面实例上暴露的方法
element_tap – 通过 CSS 选择器模拟点击 WXML 元素；支持 [index=N] 语法选择第 N 个元素；支持 x/y 坐标偏移点击；增强稳定性：等待元素可交互状态，点击后自动验证页面路径是否变化
element_input – 向元素输入文本（适用于 input 和 textarea 组件）
element_callMethod – 调用自定义组件实例的方法
element_getData – 获取自定义组件实例的渲染数据
element_setData – 设置自定义组件实例的渲染数据
element_getInnerElement – 获取元素内的元素（相当于 element.$(selector)），返回元素摘要信息；设置 withWxml: true 可额外返回完整 outerWxml
element_getInnerElements – 获取元素内的元素数组（相当于 element.$$(selector)），返回元素摘要信息；设置 withWxml: true 可额外返回每个元素的完整 outerWxml
element_getWxml – 获取元素 WXML（内部或外部）
element_getStyles – 获取元素的 CSS 样式值，names 参数为样式名数组（如 ['color', 'fontSize']）
element_scrollTo – 滚动 scroll-view 组件到指定位置（x, y）
element_getAttributes – 获取元素的特性值，names 参数为特性名数组（如 ['class', 'id', 'data-index']）
element_getBoundingClientRect – 获取元素相对于视口的边界矩形信息（left、top、width、height、right、bottom），考虑 CSS transform 变换；选择器支持微信小程序 SelectorQuery 子集（ID、class、连续 class、子代、后代、跨自定义组件后代和并集选择器）
每个工具都接受可选的 connection 块来覆盖环境默认值（项目路径、CLI 路径、WebSocket 端点等）。
element_getBoundingClientRect 选择器规则selector 和 innerSelector 使用微信小程序 SelectorQuery.select 的选择器子集：
ID 选择器：#the-id
class 选择器：.a-class
连续 class：.a-class.another-class
子代选择器：.the-parent > .the-child
后代选择器：.the-ancestor .the-descendant
跨自定义组件后代选择器：.the-ancestor >>> .the-descendant
多选择器并集：#a-node, .some-other-nodes
不支持标签选择器（如 view）、属性选择器、伪类、相邻/兄弟选择器。若目标元素位于自定义组件内部，建议 selector 指向当前页面 WXML 中直接引用的组件节点，再用 innerSelector 定位组件内部元素。
mp_mockWxMethod 只开放少量安全的 mockWxMethod 能力，当前用于 mock wx.request。同一个工具同时支持设置和恢复：
{
"action": "mock",
"method": "request",
"requestRules": [
{
"url": "/api/user",
"match": "contains",
"method": "GET",
"statusCode": 200,
"data": {
"id": 1,
"name": "test"
}
}
]
}match 支持 contains、exact、regex。命中规则的请求会返回配置的成功响应；未命中规则时透传原始 wx.request。需要恢复时：
{
"action": "restore",
"method": "request"
}连接前，在微信开发者工具中启用自动化（设置 → 安全设置 → 服务端口）
推荐首先调用 mp_ensureConnection 来验证连接并查看系统/页面详情
使用 WEAPP_AUTOCLOSE=true 适合无状态的一次性交互
导航时始终使用绝对路径（以 / 开头）：/pages/mine/mine
tabBar 页面使用 switchTab，普通页面使用 navigateTo
操作自定义组件时，有两种方法：
innerSelector 参数（推荐）适用于 element_tap、element_input、element_getWxml 等工具：
{
"selector": "#my-component",
"innerSelector": ".inner-button"
}selector：自定义组件的选择器
innerSelector：组件内部元素的选择器
适用于 element_getInnerElement 和 element_getInnerElements：
{
"selector": "#my-component",
"targetSelector": ".inner-button"
}page_waitElement 不适用于自定义组件内部元素。请使用 page_waitTimeout 配合元素查询工具进行轮询检查。
当配置 WEAPP_AUTOLAUNCH=true 时，MCP 服务器可以自动检测并启动微信开发者工具：
自动检测端口：检测 9420 端口是否有服务运行
无服务则启动：如果端口未占用，自动调用 CLI 启动开发者工具
项目选择：
如果有默认项目配置，自动使用
如果没有默认项目，自动列出最近项目供选择
支持输入项目编号（如 1）或完整路径
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": ["-y", "weapp-dev-mcp"],
"env": {
"WEAPP_AUTOLAUNCH": "true",
"WEAPP_PROJECT_PATH": "D:\\path\\to\\your\\project"
}
}
}
}首次连接时，检测到 WEAPP_AUTOLAUNCH=true
检查 9420 端口是否有服务
无服务则自动启动开发者工具（使用 cli.bat auto --project <path> --auto-port 9420）
等待 45 秒让开发者工具就绪
建立 WebSocket 连接
后续连接自动复用现有连接
提示：使用
mp_setDefaultProject设置默认项目后，下次连接无需再次选择项目。
调用组件实例指定方法，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing behavioral traits like destructiveness, side effects, or failure behavior. The brevity leaves the agent guessing about important behavioral aspects.
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 a single concise sentence that is front-loaded with the action. It avoids unnecessary words, though it could be more informative without losing conciseness.
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 the tool's complexity (5 parameters, nested connection object, no output schema), the description is severely incomplete. It omits crucial context such as what methods are valid, how args should be structured, and what the return value is.
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 description coverage is 0%, and the description does not explain any parameter beyond the schema itself. Parameters like connection, method, args, and innerSelector are left entirely undocumented, forcing reliance on the raw schema which is insufficient.
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 verb 'call' and the resource 'component instance specified method', and adds the constraint 'only custom components can be used', which distinguishes it from sibling tools like page_callMethod and other element manipulation tools.
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 some guidance by noting that it is only for custom components, implying it should not be used for native components. However, it does not mention alternatives or when not to use this tool, lacking explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的特性值。names 为特性名数组（如 ['class', 'id', 'data-index']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose performance traits, error behavior (e.g., missing attribute handling), authentication needs, or side effects. Only the basic operation is mentioned.
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 sentences covering purpose and parameter semantics with no redundancy. Front-loaded with the action. Every sentence is necessary.
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 the tool's complexity (4 parameters, nested connection object, no output schema), the description is insufficient. It omits connection configuration, return value format, and typical usage patterns, leaving the agent to guess.
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?
The description explains the 'names' parameter (array of attribute names) but ignores other critical parameters like 'selector' (required) and 'innerSelector'. With schema description coverage at 0%, the description fails to compensate adequately.
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 retrieves attribute values ('获取元素的特性值') and provides an example for the 'names' parameter. It distinguishes from sibling tools like 'element_getStyles' by focusing on attributes, though not explicitly.
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 on when to use this tool versus alternatives like 'element_getData' or 'element_getStyles'. No exclusion criteria or context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素相对于视口的边界矩形信息（left、top、width、height、right、bottom）。此方法返回的是考虑 CSS transform 变换后的实际渲染尺寸和位置。支持跨组件查询：若需获取自定义组件内部元素，可将 selector 设为组件选择器，innerSelector 设为内部元素选择器。注意：目前仅支持 ID 选择器、类选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately covers behavioral traits: it returns bounding rect after applying CSS transforms, supports cross-component queries, and notes a limitation (only ID and class selectors currently supported). It does not describe error handling or side effects.
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 concise with three sentences that front-load the main purpose. Each sentence adds useful information without unnecessary verbosity.
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 no output schema, the description lists return fields and mentions a key behavior (CSS transform). However, it does not cover the 'connection' parameter, error scenarios, or what happens if the element is not found. This limits completeness for a tool with three parameters.
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 0%, so the description must compensate. It explains 'selector' and 'innerSelector' but completely omits the 'connection' parameter, which is a complex nested object. This leaves a significant gap.
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 returns bounding rectangle information (left, top, width, height, right, bottom) relative to the viewport, considering CSS transforms. It differentiates from sibling tools by specifying the exact geometric data returned.
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 a specific use case for cross-component queries using innerSelector but does not explicitly advise when to use this tool over alternatives or when not to use it. No sibling comparisons are made.
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 |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or error conditions. It only implies a read operation but lacks explicit details.
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 a single concise sentence that communicates the core purpose efficiently without waste. However, it could include more detail without becoming overly long.
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 the complexity of the input schema (nested object, 4 parameters) and no output schema, the description is insufficient. It does not explain parameters, output, or behavior, leaving significant gaps.
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 description coverage is 0% and the description does not explain the use or meaning of any parameters (connection, selector, innerSelector, path). This leaves the agent without guidance on how to populate them.
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 that the tool gets component instance rendering data and specifies it is only for custom components, which helps differentiate it from sibling tools. However, 'rendering data' is vague.
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 a constraint (only custom components) but no guidance on when to use this tool versus alternatives like element_getAttributes or element_getStyles. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素，相当于 element.$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions the withWxml option for outerWxml but does not state whether the operation is read-only, requires permissions, has side effects, or what happens if elements are not found. The behavioral profile is severely incomplete.
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 short (two sentences), but it is under-specified rather than concise. It lacks front-loading of critical information and leaves important gaps. Every sentence should earn its place, but here the first sentence is ambiguous and the second only covers one parameter.
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 the tool has five parameters, includes a nested connection object, and has no output schema, the description is woefully incomplete. It fails to explain the core logic of how the selectors work together, the return format, or any edge cases. The agent would struggle to use this tool correctly.
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 description coverage is 0%, so the description must compensate. However, it only explains the withWxml parameter, leaving selector, innerSelector, and targetSelector completely unexplained. The nested connection object is also not described. The description adds minimal value beyond the schema.
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 states 'get element within element range' but does not clarify how the three selectors (selector, innerSelector, targetSelector) relate. The analogy to element.$(selector) is misleading as it suggests only one selector. The purpose is vague and leaves ambiguity about what exactly the tool does.
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 provided on when to use this tool versus the many sibling tools like element_getInnerElements or element_getElement. There is no mention of prerequisites, context, or alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素数组，相当于 element.$$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns an array of elements and can optionally include outerWxml. However, no annotations exist, and the description omits any side effects, required permissions, error conditions, or return format details.
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 that efficiently convey the core function and an optional feature. No redundant information.
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 the complex input schema (5 parameters, including a nested connection object) and no output schema, the description is insufficient. It does not explain the connection parameter, the meaning of innerSelector, or how to use the tool correctly in context.
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?
With 0% schema description coverage, the description only explains the withWxml parameter. The roles of selector, innerSelector, and targetSelector are not clarified, leaving ambiguity for the agent. The required parameters selector and targetSelector are mentioned in schema but not explained in description.
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 gets an array of inner elements, analogous to element.$$(selector), and mentions the optional withWxml parameter. However, it does not explicitly differentiate from the sibling tool element_getInnerElement (singular).
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 provided on when to use this tool versus alternatives like element_getInnerElement, element_getAttributes, or other element methods. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的样式值。names 为样式名数组（如 ['color', 'fontSize', 'backgroundColor']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
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 fails to disclose any behavioral traits such as whether it returns computed styles, possible side effects, or error conditions. The description is minimal and does not help the agent understand tool behavior beyond the basic action.
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 very concise (one short sentence), but it lacks structure. It front-loads the purpose but omits important details. For a single-sentence description, it is efficient but not comprehensive.
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 the tool's complexity (4 parameters, nested connection object, no output schema), the description is incomplete. It does not explain how to use the 'connection' parameter, what the return value looks like, or any constraints. The agent would lack sufficient context to use it correctly.
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 description coverage is 0%. The description only explains one of four parameters ('names') with an example. It does not explain 'selector', 'innerSelector', or the complex 'connection' object. The agent would need to infer the meaning from parameter names alone.
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's purpose: '获取元素的样式值' (get element style values). It specifies the 'names' parameter as an array of style names, differentiating from sibling tools like element_getAttributes or element_getData. However, it does not explicitly distinguish from other getters.
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 on when to use this tool versus alternatives (e.g., element_getAttributes for attributes). It does not mention prerequisites or typical use cases. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素 WXML。默认获取内部 WXML(element.wxml())，设置 outer 为 true 可获取包含元素本身的 WXML(element.outerWxml())。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| outer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states it gets WXML but does not mention whether it is read-only, idempotent, or what happens on errors (e.g., element not found). No side effects or prerequisites are described.
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 extremely concise (two short sentences) and front-loads the main purpose. However, it sacrifices necessary detail for brevity, which slightly reduces its effectiveness.
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 4 parameters (one required nested object), no output schema, and no annotations, the description is severely incomplete. It fails to cover connection setup, selector semantics, and return format, leaving the agent with inadequate information to use the tool correctly.
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 description coverage is 0%, so the description must explain parameters. It only mentions 'outer' and its effect. 'connection', 'selector', and 'innerSelector' are not explained, leaving the agent without understanding of their roles or constraints.
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 retrieves element WXML, distinguishing between inner and outer WXML via the 'outer' parameter. This differentiates it from sibling tools like element_getData or element_getStyles, which retrieve different data.
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 on when to use this tool versus alternatives (e.g., element_getAttributes, element_getBoundingClientRect). The description only explains the 'outer' option but provides no context for choosing this tool.
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 |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only says 'input text' without indicating whether the tool replaces existing content, appends, or triggers events. There is no mention of side effects, permissions, or response behavior.
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 extremely concise (one short sentence), but it is under-specified for a tool with 4 parameters, nested objects, and no annotations. Conciseness should not come at the cost of essential information.
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 the tool's complexity (multiple parameters, no output schema, no annotations), the description is severely incomplete. It fails to address parameter roles, behavioral nuances, or usage context, leaving a significant knowledge gap for the agent.
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 description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not describe any parameter, including key ones like 'selector', 'value', or the complex 'connection' object. The agent is left to infer from names alone.
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 action (input text) and target (specified element), making the tool's primary purpose understandable. However, it does not differentiate from sibling tools like element_setData or element_tap, which could also involve modifying element state.
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 provided on when to use this tool versus alternatives such as element_setData or page_callMethod. The description lacks any context about prerequisites, when input is appropriate, or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
滚动 scroll-view 组件到指定位置。仅适用于 scroll-view 组件。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| x | Yes | ||
| y | Yes |
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 discloses the tool scrolls to a position and applies only to scroll-view, but lacks details on prerequisites (e.g., connection), side effects, or behavior if the element is not scrollable.
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 short and front-loaded with the core action. However, it may be too concise given the complex input schema, but it remains clear and free of unnecessary wording.
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?
The description lacks information on prerequisites (e.g., connection setup), return values, and whether scrolling is animated. Given the schema with many parameters and no output schema, this is incomplete for an agent to use effectively.
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?
With 0% schema description coverage, the description adds very little parameter context. It does not explain key parameters like selector, innerSelector, x, y, or the connection object. The agent would need to guess their meanings.
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 scrolls a scroll-view component to a specified position, and specifies it only applies to scroll-view components. This distinguishes it from sibling tools like element_tap or element_callMethod.
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 explicitly states the tool is only for scroll-view components, guiding when to use it. However, it does not mention when not to use it or suggest alternatives for non-scroll-view elements.
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 |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It omits effects like overwriting existing data, required authentication (connection parameter), or error behavior. Only 'only custom components' is stated, which is insufficient.
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 is concise and includes essential restriction, but lacks deeper structure. Could be expanded to cover parameters and behavior without becoming verbose.
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 4 parameters, nested objects, no annotations, and no output schema, the description is too sparse. It ignores connection setup, selector semantics, and output handling. Incomplete for effective use.
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 description coverage is 0%, yet description only hints at the 'data' parameter ('rendering data'). Parameters like selector, innerSelector, and connection are not explained. Minimal value added over schema.
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 the tool sets component instance rendering data and explicitly notes it is only for custom components, distinguishing it from page_setData. Verb and resource are specific.
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?
Implied usage is setting data for custom components, but no when-not-to-use or alternatives are mentioned. The sibling page_setData exists, but the description does not compare them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 CSS 选择器模拟点击 WXML 元素。支持 [index=N] 语法选择第 N 个元素。如需点击自定义组件内部的元素，请使用 innerSelector 参数：selector 设为组件 ID 选择器(如 #my-component)或标签选择器，innerSelector 设为组件内部元素的选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| waitMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It mentions simulating a click but does not specify whether it waits for visibility, the type of click (tap/long press), or any side effects. The waitMs parameter's role is unclear. This leaves significant behavioral gaps for an agent.
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 composed of two concise sentences in Chinese, front-loading the main purpose and then adding details about index syntax and innerSelector. Every sentence adds value without 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?
Given no annotations, no output schema, and a complex nested connection parameter, the description lacks details on waitMs behavior, connection requirements, and return values. It covers selector usage well but omits prerequisites and behavioral context, leaving the tool incompletely specified for autonomous use.
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 0%, so the description must compensate. It adds meaning for selector (CSS selector with index syntax) and innerSelector (component-inside-element), explaining their relationship. However, it does not explain connection or waitMs, leaving those parameters unclear. It partially offsets the low schema coverage.
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 simulates clicking a WXML element via CSS selector, distinguishing it from other element_* tools like element_input. It also details the [index=N] syntax and innerSelector for custom components, which clarifies its specific functionality.
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 explicitly explains when to use innerSelector (for custom components) and how to set parameters. However, it does not compare to alternatives like element_callMethod or page_getElement, nor does it state when not to use this tool. Still, it provides good contextual guidance for its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用微信小程序 API 方法，（如 wx.pageScrollTo）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that a connection via the 'connection' parameter is required, nor any side effects, error handling, or rate limits. The example is insufficient.
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 a single short sentence, which is concise but lacks structure. It does not front-load critical information like required parameters or return values.
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 the tool's complexity (3 parameters including a nested object, no output schema, no annotations), the description is severely incomplete. It omits prerequisites, return values, error handling, and how to use the 'connection' parameter.
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?
With 0% schema description coverage, the description must add meaning to parameters. It only mentions 'method' implicitly and ignores 'connection' and 'args', failing to explain their roles or requirements.
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 calls WeChat Mini Program API methods like `wx.pageScrollTo`, indicating a specific verb and resource. It distinguishes from sibling tools like `mp_navigate` which are for specific operations, but the description is broad.
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 on when to use this tool versus alternatives such as `mp_navigate` or `mp_screenshot`. The description lacks context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前页面的信息，包括路径、查询参数、尺寸和滚动位置。通常在 mp_ensureConnection 成功后立即调用，用于确认当前页面。withData 为 true 时额外返回页面数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| withData | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It truthfully states the tool retrieves information without implying side effects, though it could explicitly state it is a read-only operation. The optional return of page data with withData is disclosed.
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 extremely concise with two short sentences, no filler, and front-loads the purpose. Every sentence adds value.
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 the tool has a complex nested parameter and no output schema, the description is incomplete. It omits details about the connection parameter and what the return data contains (beyond path, query, size, scroll). The usage context helps, but key aspects are missing.
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 description coverage is 0%, so the description must explain parameters. It only explains the withData parameter ('when true, additionally returns page data') but provides no explanation for the complex 'connection' nested object with many properties, leaving its semantics unclear.
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 that the tool retrieves current page information including path, query parameters, size, and scroll position. It distinguishes itself from siblings like page_getData or page_callMethod by focusing on the page's current state. The mention of typical usage after mp_ensureConnection further clarifies its role.
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 explicitly recommends calling this tool after mp_ensureConnection succeeds, providing clear usage context. It also explains when to set withData=true for additional data. However, it does not mention when not to use this tool or alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查小程序自动化会话是否就绪。先调用这个工具，再调用 mp_screenshot、page_* 或 element_* 工具。若失败，优先用 reconnect=true 重试一次；若返回项目选择提示，则传 projectSelection。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| reconnect | No | ||
| projectSelection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses the tool's main behavior (checking readiness) and failure modes (retry with reconnect, project selection handling). It lacks details on side effects or what happens on success, but the disclosed behaviors are sufficient for basic usage.
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 sentences, the first clearly stating purpose and prerequisite order, the second detailing failure handling. No redundant information, front-loaded, and efficiently communicates key points.
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 the complexity (nested connection object, no output schema, no annotations), the description is incomplete. It does not explain the connection parameters or what 'ready' means in terms of output. The tool is critical for session setup but leaves significant ambiguity about its inputs and results.
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?
The schema has 0% description coverage, so the description must compensate. It mentions reconnect and projectSelection, but the main connection object (with 15 properties) is not explained. The agent gets partial semantics for two parameters, but the core input remains opaque.
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 if the mini-program automation session is ready, using the verb '检查' (check) on the resource '会话' (session). It further differentiates itself by specifying it's a prerequisite for screenshot, page_, and element_ tools.
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 explicitly instructs to call this tool first before others, and provides specific failure handling: retry with reconnect=true for general failure, and pass projectSelection if a project selection prompt appears. This gives clear when-to-use and alternative actions.
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 |
|---|---|---|---|
| connection | No | ||
| clear | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states get logs and optionally clear, but does not explain side effects of clearing, connection prerequisites, or behavior in edge cases. The complex 'connection' parameter is left undefined.
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 sentences, front-loaded with purpose, no redundancy. However, could be expanded with a brief note on connection prerequisites or return format without harming conciseness.
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?
Despite complex nested 'connection' object (16 sub-properties) and no output schema, the description provides zero context on connection setup, expected response, or log contents. Inadequate for an AI agent to use correctly.
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 0% (no parameter descriptions). Description only mentions 'logs' and 'clear' but does not explain the 'connection' object's properties or the exact effect of 'clear' (e.g., clears logs permanently?). User must infer from parameter names.
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 verb '获取' (Get) and resource '小程序控制台日志' (mini program console logs), with optional clearing. This distinguishes it from sibling tools which cover other mini program operations like calling wx, navigating, screenshots.
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 when to use this tool versus others, no precondition hints (e.g., requires connection), and no exclusion scenarios. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出微信开发者工具中的最近项目，方便在 mp_ensureConnection 返回项目选择提示后继续选择项目。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it lists recent projects, without mentioning side effects, permissions, or output format. For a tool that presumably performs a read operation, this is minimal disclosure.
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 a single sentence that efficiently conveys purpose and usage context without any redundant information. It is appropriately sized and 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 the absence of an output schema and annotations, the description is minimally complete: it explains what the tool does and when to use it. However, it lacks details about the output format (e.g., list of project names or IDs) and any constraints, which could be useful for an AI agent.
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?
The input schema has no parameters, and schema description coverage is 100%. With 0 parameters, the baseline is 4. The description adds context by specifying the scope as 'recent projects', which is helpful but not required.
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 lists recent projects in WeChat Developer Tools, using the verb 'list' and specifying the resource as 'recent projects'. It provides a usage context (after mp_ensureConnection returns a project selection prompt), but does not explicitly differentiate from sibling tools like mp_setDefaultProject or mp_navigate.
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 gives a specific usage scenario: using this tool after mp_ensureConnection returns a project selection prompt. However, it does not provide explicit guidance on when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
截取当前小程序视口的截图。需要已有活动会话；若提示没有活动会话，请先调用 mp_ensureConnection。默认返回内联图片，或保存到文件路径。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that a screenshot is captured, active session is required, and output defaults to inline image or file save. However, it does not detail potential side effects or error conditions beyond the session prompt.
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 short sentences with no filler. The main action is first, followed by prerequisite and output behavior. Every sentence adds value.
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 the tool's complexity (nested connection parameter, no annotations, no output schema), the description covers the core purpose and usage context but leaves the connection parameter unexplained. It references mp_ensureConnection but does not fully describe the connection setup.
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 description coverage is 0%, so the description must compensate. It explains the 'path' parameter (save to file) but provides no explanation for the complex 'connection' parameter. Users must rely on external knowledge or sibling tool mp_ensureConnection.
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's action: 'take a screenshot of the current mini-program viewport' (specific verb and resource). It distinguishes itself from siblings by focusing on screenshot capture, while other tools like mp_currentPage retrieve page info.
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?
Explicitly mentions the prerequisite of an active session and directs users to call mp_ensureConnection if none exists. This provides clear when-to-use and alternative step guidance.
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 |
|---|---|---|---|
| projectPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that setting the default affects the next connection, adding behavioral context beyond the absent annotations. However, it does not mention potential side effects, permissions, or reversibility, limiting full transparency.
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 concise sentences, front-loaded with the primary action and use case, 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 setter tool with one parameter and no output schema, the description covers purpose and typical usage scenario, but misses details on return values, error states, or prerequisites. It is largely complete given the tool's simplicity.
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?
The input schema has one parameter with 0% description coverage, and the description does not mention the parameter or its intended use, providing no additional meaning beyond the schema.
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 verb 'set' and the resource 'default mini-program project path', and distinguishes its purpose from sibling tools by specifying it is used for retrying after project selection failure.
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 a clear use case: 'usually used for retry after project selection failure.' It implies when to use but does not explicitly mention when not to use or alternatives.
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 |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action (call a method) and that args can be an array, but does not disclose side effects, error behavior (e.g., unknown method), or any requirements like a valid connection. This is insufficient for zero 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?
The description is very concise (two sentences) and front-loaded with the purpose. However, given the complexity of the tool (many schema properties), it is under-specified. Every sentence earns its place but more structure (e.g., listing important connection options) would help.
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?
The tool is complex with a nested connection object and three parameters, yet the description provides almost no additional context beyond a one-line summary. There is no output schema, so the description should explain return values or behavior, which it does not. The description is far from complete 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the three parameters (connection, method, args). It only mentions that 'args can be provided as an array', which is already evident from the schema. The complex 'connection' object is completely unexplained, and the 'method' field is not elaborated. With 0% coverage, the description should compensate heavily but fails.
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 verb 'call' and the resource 'methods exposed on the current page instance'. It is not a tautology and provides a specific action. However, it does not differentiate from sibling tool 'element_callMethod', which calls methods on elements, so it loses a point.
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 no guidance on when to use this tool versus alternatives like 'element_callMethod' or when not to use it. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
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 |
|---|---|---|---|
| connection | No | ||
| path | No |
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 only states 'get', implying a read operation, but does not disclose any behavioral traits such as side effects, permissions, or rate limits. The description lacks explicit safety or state-change information.
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 a single concise sentence, front-loading the purpose. It is efficient in length, but could be more structured to cover multiple aspects (e.g., parameter explanation, usage context). The conciseness is good, but sacrificing completeness.
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 the tool's complexity (nested connection object, no annotations, no output schema), the description is severely incomplete. It does not address the critical connection parameter, nor does it provide any context about return values, prerequisites, or the overall workflow. The agent lacks essential information to use the tool correctly.
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 description coverage is 0%, requiring the description to compensate. The description briefly explains the 'path' parameter as a sub-data path, but completely omits explanation of the 'connection' parameter, which is a complex nested object with many subproperties. This leaves the agent uninformed about the primary parameter.
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 gets the current page's data object, with an optional sub-path. It specifically mentions 'current page', distinguishing it from sibling element-level tools like element_getData. The verb 'get' and resource are explicit.
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 this tool vs alternatives. The description implies it's for page data, but does not mention when not to use it or suggest alternatives like element_getData for element-level data. The context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素，相当于 page.$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains returned fields and the withWxml option, but omits critical details such as the need for a connection, error handling (e.g., element not found), and whether the tool waits or returns immediately.
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?
Three concise sentences, each serving a clear purpose: stating equivalency, listing returns and toggles, and noting index syntax. No wasted 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?
Given the absence of annotations and output schema, the description is incomplete. It fails to cover connection requirements, return value when element is missing, or distinguish from sibling tools.
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 0%, so the description must compensate. It adds meaning for selector (CSS selector, index syntax) and withWxml (returns outerWxml), but provides no information about the required connection object or the optional innerSelector parameter.
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 states that the tool gets a page element by selector, equivalent to page.$(), and lists returned fields. However, it does not explicitly differentiate from the sibling tool page_getElements, which likely returns multiple elements.
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 implies usage when a selector and element information is needed, but it does not provide explicit guidance on when to use this tool instead of alternatives like page_getElements or other element tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素数组，相当于 page.$$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return structure and the effect of withWxml, and mentions [index=N] syntax. However, it does not explain behavior on no matches, error handling, or the connection parameter's role.
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?
Description is concise, front-loaded with the main action, and each sentence adds value. No unnecessary repetition.
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?
The tool has 3 parameters and no output schema. The description explains return fields and the withWxml option, but does not cover the connection parameter or behavior when selector matches nothing. Adequate but incomplete.
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 0%, so description must compensate. It explains selector and withWxml well, but completely omits the connection parameter, which is a complex nested object. Two out of three parameters are covered, but the missing one is significant.
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 the tool gets an array of page elements via selector, equivalent to page.$$(), and lists returned fields. It distinguishes from sibling tools like page_getElement by specifying it returns multiple elements.
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 implies usage for multiple elements via the 'equivalent to page.$$' phrase and mentions the withWxml option. However, it does not explicitly state when not to use or provide alternatives, though sibling names offer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 setData 更新当前页面的数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states that it updates data, with no details on side effects, permissions, or error conditions. No annotations provided to supplement.
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 is concise but too brief, missing essential context for effective use.
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?
With no annotations, output schema, or parameter descriptions, the description is severely incomplete for a tool that modifies page data.
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 has 0% description coverage and the description adds no information about parameters. The required 'data' parameter remains undocumented.
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 action (update) and target (current page's data), but lacks differentiation from sibling tools like element_setData or page_getData.
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 on when to use this tool versus alternatives like element_setData or page_getData, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
等待指定选择器的元素出现在页面上。支持 [index=N] 语法选择第 N 个元素。增强版：增加了超时和重试间隔参数。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| timeout | No | ||
| retryInterval | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions timeout and retry interval, but does not specify behavior on failure (e.g., timeout error), return value, or side effects. The description is insufficient for an agent to fully predict tool behavior.
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 concise at two sentences. It front-loads the primary purpose and then adds secondary features. No redundant information. However, it could be slightly more structured by separating core purpose from enhancements.
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 the tool has a complex 'connection' parameter, no output schema, and no annotations, the description is incomplete. It omits explanation of the connection object, error handling, and return values. The description only covers selector semantics and basic retry/timeout, leaving major gaps.
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 description coverage is 0%, so the description must compensate. It adds meaning to the selector parameter by explaining the [index=N] syntax. It also states timeout and retry interval are 'enhanced' parameters. However, the complex 'connection' object is left unexplained, and other parameters lack context.
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 waits for an element specified by a selector to appear on the page. It mentions support for [index=N] syntax, which adds clarity about selecting specific elements. However, it does not explicitly distinguish this tool from siblings like page_waitTimeout or page_getElement, which could lead to confusion.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, common use cases, or when not to use it. The sibling tools suggest broader workflow, but no explicit context is given.
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 |
|---|---|---|---|
| connection | No | ||
| milliseconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action of waiting and does not cover whether the wait is blocking, cancellable, or how it interacts with page lifecycle. No additional traits are mentioned.
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 a single short sentence, which is concise but lacks structure. It does not front-load key information or use formatting to aid readability. While efficient, it sacrifices necessary detail.
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 the tool has multiple parameters (including a nested connection object) and no annotations or output schema, the description is severely incomplete. It omits return behavior, error conditions, and prerequisites, leaving the agent with insufficient context for correct invocation.
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 description coverage is 0%, and the description adds no explanation for either parameter. The 'milliseconds' parameter is somewhat self-explanatory from its name, but the complex 'connection' object is completely undocumented. The description fails to provide any semantic value beyond the schema structure.
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 waits for a specified number of milliseconds. The name 'page_waitTimeout' implies time-based waiting, and the description confirms the unit. However, it does not differentiate from sibling tools like page_waitElement, which wait for a condition rather than a fixed duration.
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 provided on when to use this tool versus alternatives. The description does not mention scenarios where a fixed delay is preferable to conditional waits, nor does it provide context on prerequisites or side effects.
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.
v0.2.4element_callMethodelement_getAttributeselement_getBoundingClientRectelement_getDataelement_getInnerElementelement_getInnerElementselement_getStyleselement_getWxmlelement_inputelement_scrollToelement_setDataelement_tapmp_callWxmp_currentPagemp_ensureConnectionmp_getLogsmp_listProjectsmp_navigatemp_screenshotmp_setDefaultProjectpage_callMethodpage_getDatapage_getElementpage_getElementspage_setDatapage_waitElementpage_waitTimeoutv0.1.6element_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutv1.0.0element_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElements2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getSize2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getWxml2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_input2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_tap2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_callWx2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_ensureConnection2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_getLogs2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_navigate2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_screenshot2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitTimeout2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutScored across 27 tools
Each tool targets a distinct action within its category (element, mp, page). Within each group, operations like getAttributes, getBoundingClientRect, getData are clearly different. No two tools overlap in purpose.
All tools follow a consistent pattern: category_verbNoun (e.g., element_tap, mp_navigate, page_setData). Underscore separation and camelCase for the verb+noun are uniform across all 27 tools.
With 27 tools, the count is on the higher side but well-justified by the broad scope (element manipulation, page control, and mini-program API calls). It's reasonably scoped for a comprehensive development assistant.
The tool set covers core operations: element querying/interaction, page data management, and mini-program API invocation. Minor gaps like gesture simulation or file operations exist, but the essential CRUD and lifecycle actions are present.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Give your AI agents the tools to build, manage, and run automation workflows.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
