This server enables AI assistants to automate testing and interaction with WeChat Mini Programs through MCP tools, similar to Playwright but specialized for the WeChat ecosystem.
Application Management
Establish and manage automation sessions with WeChat Developer Tools via WebSocket or CLI launch
Navigate within mini programs using navigateTo, redirectTo, reLaunch, switchTab, and navigateBack
Capture screenshots of the current viewport
Call WeChat Mini Program API methods (e.g., wx.showToast)
Retrieve and optionally clear console logs
Get current page information including path, query parameters, dimensions, scroll position, and data
Page Operations
Query single or multiple elements using CSS selectors
Wait for elements to appear or for specific timeouts
Get and set page data objects using the setData mechanism
Call methods exposed on page instances
Element Interactions
Simulate tap/click events and text input on WXML elements
Get element properties: WXML (inner/outer), styles, attributes, size, and bounding rectangles
Query nested elements within other elements (element.$ and element.$$)
Scroll scroll-view components to specific positions
Custom Component Support
Access elements inside custom components using innerSelector parameter
Call methods and get/set rendering data on custom component instances (requires automator 0.6.0+ and base library 2.9.0+)
Flexible Configuration
Configure connection mode, CLI path, ports, timeouts, and authentication via environment variables
Override connection settings on individual tool calls
Launch new Developer Tools instances or connect to existing ones
Automates WeChat Developer Tools for WeChat Mini Programs, enabling navigation, inspection, and manipulation of mini-program pages, elements, and components through the miniprogram-automator API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WeChat Mini Program Dev MCP navigate to the user profile page and take a screenshot"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A FastMCP-based server that automates WeChat Developer Tools via miniprogram-automator. This server provides MCP tools that allow AI assistants to navigate, inspect, and manipulate mini program pages—similar to playwright-mcp, but tailored for the WeChat ecosystem.
WeChat Developer Tools installed with command-line access (cli / cli.bat) enabled.
Node.js 18+ and npm installed locally.
A mini program project that can be opened in the Developer Tools.
Related MCP server: weapp-agent-mcp
@yfme/weapp-dev-mcp has been published to npm. Regular users do not need to clone the repository or manually execute node dist/index.js.
npx -y @yfme/weapp-dev-mcpnpm install -g @yfme/weapp-dev-mcp
weapp-dev-mcpOr as a project dependency:
npm install --save-dev @yfme/weapp-dev-mcp
npx weapp-dev-mcpOnly when developing within this repository is it recommended to run
node dist/index.jsdirectly. General users should start via the npm package method above.
To use this server in Claude Desktop or other MCP clients, add the following to your configuration file:
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": [
"-y",
"@yfme/weapp-dev-mcp"
],
"env": {
"WEAPP_WS_ENDPOINT": "ws://localhost:9420"
}
}
}
}Since calling MCP tools via Claude Code triggers tool permission requests, the connection state between the MCP and WeChat Developer Tools might be lost. Because retrieving console output is highly dependent on the connection state, it may be impossible to obtain output logs coherently. Therefore, it is recommended to add permissions manually:
Create a .claude/settings.local.json file in your project directory, or add the following content to an existing file to allow direct tool calls without confirmation, or add the specific tools you wish to allow without confirmation as needed:
{
"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_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_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"
]
}
}Note: The tool name format is
mcp__<server_name>__<tool_name>. Please ensure the server name matches the one in your MCP configuration.
Before using the MCP server, you must start the WeChat Developer Tools and enable the WebSocket service.
💡 Before you begin:
Open WeChat Developer Tools.
Go to Settings → Security Settings → Service Port.
Enable "HTTP Debugging" and "Automation Testing".
Start via Command Line
Use the command line to start WeChat Developer Tools and automatically enable the WebSocket service:
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 9420Where:
--project specifies the path to the mini program project directory (please replace with the actual project path).
--auto-port specifies the WebSocket service port (default is 9420).
⚠️ Warning Due to sandbox mechanisms, some clients do not allow MCP to access the WeChat Developer Tools CLI outside of the project directory, so only the WebSocket service method is introduced here.
Control how the automation tool connects to WeChat Developer Tools via environment variables:
Variable | Description |
| [Recommended] The WebSocket endpoint of the running Developer Tools. When set, the server uses |
| Path to the WeChat Developer Tools CLI (optional if the default path works). |
| Force |
| Preferred port when launching Developer Tools (falls back to an available port). |
| Launch timeout in milliseconds (default 30000). |
| Passed to |
| Passed to |
| Set to |
| Additional CLI arguments at launch (space-separated). |
| Working directory passed to the Developer Tools process. |
| Set to |
| Set to |
| Launch timeout in milliseconds (default 45000). |
| Connection timeout in milliseconds (default 45000). |
| Mini program project path (optional). |
Note: When launching Developer Tools (
launchmode), you must provide the mini program project directory via MCP tool parameters: provide it viaconnection.projectPathbefore performing operations (e.g., viamp_ensureConnection). Once established, this value will persist in subsequent calls.
Tool calls can override most of these defaults via the connection object.
mp_ensureConnection – Ensures the automation session is ready; optionally force reconnect or override connection settings.
mp_navigate – Navigate within the mini program; supports navigateTo, redirectTo, reLaunch, switchTab, or navigateBack.
mp_screenshot – Capture a screenshot and return it (or save to disk).
mp_callWx – Call WeChat Mini Program API methods (e.g., wx.showToast).
mp_getLogs – Retrieve mini program console logs, optionally clearing them after retrieval.
mp_currentPage – Get current page information (path, query parameters, dimensions, scroll position); returns page data if withData is true.
mp_listProjects – List recent projects in WeChat Developer Tools for easy selection of project directories.
mp_setDefaultProject – Set the default mini program project path; once set, the next connection will automatically use this project.
page_getElement – Get a page element via selector, returns element summary (tagName, text, value, size, offset); set withWxml: true to additionally return the full outerWxml; supports [index=N] syntax to select the Nth element.
page_getElements – Get an array of page elements via selector, returns summary for each; set withWxml: true to additionally return the full outerWxml for each; supports [index=N] syntax.
page_waitElement – Wait for an element to appear on the page (⚠️ not applicable to elements inside custom components); supports [index=N] syntax; adds timeout and retry interval parameters.
page_waitTimeout – Wait for a specified number of milliseconds.
page_getData – Get the data object of the current page, can specify a path (supports nested paths like 'user.name').
page_setData – Update the current page's data using setData; adds a verify option to confirm if data was actually updated successfully.
page_callMethod – Call a method exposed on the current page instance.
element_tap – Simulate a tap on a WXML element via CSS selector; supports [index=N] syntax to select the Nth element; supports x/y coordinate offset tapping; enhanced stability: waits for element interactivity, automatically verifies if the page path changed after tapping.
element_input – Input text into an element (applicable to input and textarea components).
element_callMethod – Call a method on a custom component instance.
element_getData – Get rendering data of a custom component instance.
element_setData – Set rendering data of a custom component instance.
element_getInnerElement – Get an element inside an element (equivalent to element.$(selector)), returns element summary; set withWxml: true to additionally return the full outerWxml.
element_getInnerElements – Get an array of elements inside an element (equivalent to element.$$(selector)), returns element summary; set withWxml: true to additionally return the full outerWxml for each.
element_getWxml – Get element WXML (inner or outer).
element_getStyles – Get CSS style values of an element, names parameter is an array of style names (e.g., ['color', 'fontSize']).
element_scrollTo – Scroll a scroll-view component to a specified position (x, y).
element_getAttributes – Get attribute values of an element, names parameter is an array of attribute names (e.g., ['class', 'id', 'data-index']).
element_getBoundingClientRect – Get the bounding rectangle information of an element relative to the viewport (left, top, width, height, right, bottom), considering CSS transforms (currently only supports ID and class selectors).
Each tool accepts an optional connection block to override environment defaults (project path, CLI path, WebSocket endpoint, etc.).
Before connecting, enable automation in WeChat Developer Tools (Settings → Security Settings → Service Port).
It is recommended to call mp_ensureConnection first to verify the connection and view system/page details.
Using WEAPP_AUTOCLOSE=true is suitable for stateless, one-off interactions.
Always use absolute paths when navigating (starting with /): /pages/mine/mine.
Use switchTab for tabBar pages, and navigateTo for regular pages.
There are two ways to operate custom components:
innerSelector parameter (Recommended)Applicable to tools like element_tap, element_input, element_getWxml, etc.:
{
"selector": "#my-component",
"innerSelector": ".inner-button"
}selector: The selector for the custom component.
innerSelector: The selector for the element inside the component.
Applicable to element_getInnerElement and element_getInnerElements:
{
"selector": "#my-component",
"targetSelector": ".inner-button"
}page_waitElement does not apply to elements inside custom components. Please use page_waitTimeout in conjunction with element query tools for polling checks.
When WEAPP_AUTOLAUNCH=true is configured, the MCP server can automatically detect and launch WeChat Developer Tools:
Auto-detect port: Detects if a service is running on port 9420.
Launch if no service: If the port is not occupied, it automatically calls the CLI to launch the Developer Tools.
Project selection:
If a default project is configured, it is used automatically.
If no default project exists, it automatically lists recent projects for selection.
Supports entering a project number (e.g., 1) or the full path.
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": ["-y", "weapp-dev-mcp"],
"env": {
"WEAPP_AUTOLAUNCH": "true",
"WEAPP_PROJECT_PATH": "D:\\path\\to\\your\\project"
}
}
}
}Upon first connection, WEAPP_AUTOLAUNCH=true is detected.
Checks if a service is running on port 9420.
If no service, automatically launches Developer Tools (using cli.bat auto --project <path> --auto-port 9420).
Waits 45 seconds for the Developer Tools to be ready.
Establishes a WebSocket connection.
Subsequent connections automatically reuse the existing connection.
Tip: After setting a default project using
mp_setDefaultProject, you do not need to select the project again for the next connection.
调用组件实例指定方法，仅自定义组件可以使用。
| 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. Dates show when Glama detected each change.
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_waitTimeoutEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yfmeii/weapp-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
