Un servidor basado en FastMCP que automatiza las Herramientas de Desarrollo de WeChat a través de miniprogram-automator. Este servidor proporciona herramientas MCP que permiten a los asistentes de IA navegar, inspeccionar y manipular páginas de mini programas, similar a playwright-mcp, pero personalizado para el ecosistema de WeChat.
Tener instaladas las Herramientas de Desarrollo de WeChat con soporte para acceso por línea de comandos (cli / cli.bat).
Node.js 18+ y npm instalados localmente.
Un proyecto de mini programa que se pueda abrir en las herramientas de desarrollo.
Related MCP server: weapp-agent-mcp
@yfme/weapp-dev-mcp ha sido publicado en npm; los usuarios comunes no necesitan clonar el repositorio ni ejecutar manualmente node dist/index.js.
npx -y @yfme/weapp-dev-mcpnpm install -g @yfme/weapp-dev-mcp
weapp-dev-mcpO como dependencia del proyecto:
npm install --save-dev @yfme/weapp-dev-mcp
npx weapp-dev-mcpSolo se recomienda ejecutar
node dist/index.jsdirectamente cuando se desarrolla dentro de este repositorio. Los usuarios generales deben iniciar siguiendo el método del paquete npm anterior.
Para usar este servidor en Claude Desktop u otros clientes MCP, añada lo siguiente al archivo de configuración:
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": [
"-y",
"@yfme/weapp-dev-mcp"
],
"env": {
"WEAPP_WS_ENDPOINT": "ws://localhost:9420"
}
}
}
}Debido a que al usar Claude Code para invocar herramientas MCP se solicita permiso de ejecución, esto puede provocar la pérdida del estado de conexión entre el MCP y las Herramientas de Desarrollo de WeChat. Dado que la obtención de la salida de la consola depende en gran medida del estado de la conexión, no será posible obtener registros de forma coherente, por lo que se recomienda añadir permisos manualmente:
Cree un archivo .claude/settings.local.json en el directorio del proyecto, o añada el siguiente contenido a un archivo existente para permitir la invocación directa sin confirmación, o añada las herramientas que desee permitir:
{
"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"
]
}
}Nota: El formato del nombre de la herramienta es
mcp__<nombre-servidor>__<nombre-herramienta>. Asegúrese de que el nombre del servidor coincida con el de su configuración MCP.
Antes de usar el servidor MCP, debe iniciar las Herramientas de Desarrollo de WeChat y habilitar el servicio WebSocket.
💡 Antes de comenzar:
Abra las Herramientas de Desarrollo de WeChat.
Vaya a Configuración → Configuración de seguridad → Puerto de servicio.
Habilite "Depuración HTTP" y "Pruebas automatizadas".
Iniciar mediante línea de comandos
Use la línea de comandos para iniciar las Herramientas de Desarrollo de WeChat y habilitar automáticamente el servicio WebSocket:
macOS/Linux:
/Applications/wechatwebdevtools.app/Contents/MacOS/cli auto --project /path/to/your/project --auto-port 9420Windows:
"C:\Program Files (x86)\Tencent\微信web开发者工具\cli.bat" auto --project C:\path\to\your\project --auto-port 9420Donde:
El parámetro --project especifica la ruta del directorio del proyecto del mini programa (reemplácelo por la ruta real).
El parámetro --auto-port especifica el puerto del servicio WebSocket (por defecto 9420).
⚠️ Advertencia Debido al mecanismo de sandbox, algunos clientes no permiten que el MCP acceda al CLI de las Herramientas de Desarrollo de WeChat fuera del directorio del proyecto, por lo que aquí solo se ha introducido el uso del servicio WebSocket.
Controle cómo la herramienta de automatización se conecta a las Herramientas de Desarrollo de WeChat mediante variables de entorno:
Variable | Descripción |
| 【Recomendado】 Punto final WebSocket de las herramientas de desarrollo ya en ejecución. Si se establece, el servidor usa el modo |
| Ruta del CLI de las Herramientas de Desarrollo de WeChat (opcional si la ruta por defecto es válida). |
| Fuerza el uso del modo |
| Puerto preferido al iniciar las herramientas de desarrollo (vuelve a un puerto disponible). |
| Tiempo de espera de inicio (ms, por defecto 30000). |
| Pasado a |
| Pasado a |
| Establecer en |
| Argumentos CLI adicionales al iniciar (separados por espacios). |
| Directorio de trabajo pasado al proceso de las herramientas de desarrollo. |
| Si se establece en |
| Si se establece en |
| Tiempo de espera de inicio (ms, por defecto 45000). |
| Tiempo de espera de conexión (ms, por defecto 45000). |
| Ruta del proyecto del mini programa (opcional). |
Nota: Al iniciar las herramientas de desarrollo (modo
launch), debe proporcionar el directorio del proyecto del mini programa a través de los parámetros de la herramienta MCP: proporciónelo a través deconnection.projectPathantes de realizar operaciones (por ejemplo, mediantemp_ensureConnection). Una vez establecido, este valor persistirá en llamadas posteriores.
Las llamadas a herramientas pueden sobrescribir la mayoría de estos valores predeterminados a través del objeto connection.
mp_ensureConnection – Asegura que la sesión de automatización esté lista; permite forzar la reconexión o sobrescribir la configuración de conexión.
mp_navigate – Navega dentro del mini programa, admite navigateTo, redirectTo, reLaunch, switchTab o navigateBack.
mp_screenshot – Captura una captura de pantalla y la devuelve (o la guarda en el disco).
mp_callWx – Llama a métodos de la API de mini programas de WeChat (como wx.showToast).
mp_getLogs – Obtiene los registros de la consola del mini programa, con opción de borrarlos después de obtenerlos.
mp_currentPage – Obtiene información de la página actual (ruta, parámetros de consulta, dimensiones, posición de desplazamiento); si withData es true, devuelve adicionalmente los datos de la página.
mp_listProjects – Lista los proyectos recientes en las Herramientas de Desarrollo de WeChat para facilitar la selección del directorio del proyecto.
mp_setDefaultProject – Establece la ruta predeterminada del proyecto del mini programa; una vez establecida, la próxima conexión usará automáticamente este proyecto.
page_getElement – Obtiene un elemento de la página mediante un selector, devuelve un resumen del elemento (tagName, text, value, size, offset); establecer withWxml: true devuelve adicionalmente el outerWxml completo; admite la sintaxis [index=N] para seleccionar el N-ésimo elemento.
page_getElements – Obtiene una matriz de elementos de la página mediante un selector, devuelve un resumen de cada elemento; establecer withWxml: true devuelve adicionalmente el outerWxml completo de cada elemento; admite la sintaxis [index=N].
page_waitElement – Espera a que un elemento aparezca en la página (⚠️ no aplicable a elementos dentro de componentes personalizados); admite la sintaxis [index=N]; añade parámetros de tiempo de espera e intervalo de reintento.
page_waitTimeout – Espera un número específico de milisegundos.
page_getData – Obtiene el objeto de datos de la página actual, se puede especificar una ruta (admite rutas anidadas como 'user.name').
page_setData – Actualiza los datos de la página actual usando setData; añade la opción verify para verificar si los datos se actualizaron correctamente.
page_callMethod – Llama a un método expuesto en la instancia de la página actual.
element_tap – Simula un clic en un elemento WXML mediante un selector CSS; admite la sintaxis [index=N] para seleccionar el N-ésimo elemento; admite clics con desplazamiento de coordenadas x/y; mayor estabilidad: espera a que el elemento sea interactivo y verifica automáticamente si la ruta de la página cambió después del clic.
element_input – Introduce texto en un elemento (aplicable a componentes input y textarea).
element_callMethod – Llama a un método de una instancia de componente personalizado.
element_getData – Obtiene los datos de renderizado de una instancia de componente personalizado.
element_setData – Establece los datos de renderizado de una instancia de componente personalizado.
element_getInnerElement – Obtiene un elemento dentro de otro elemento (equivalente a element.$(selector)), devuelve un resumen del elemento; establecer withWxml: true devuelve adicionalmente el outerWxml completo.
element_getInnerElements – Obtiene una matriz de elementos dentro de otro elemento (equivalente a element.$$(selector)), devuelve un resumen del elemento; establecer withWxml: true devuelve adicionalmente el outerWxml completo de cada elemento.
element_getWxml – Obtiene el WXML de un elemento (interno o externo).
element_getStyles – Obtiene los valores de estilo CSS de un elemento, el parámetro names es una matriz de nombres de estilo (como ['color', 'fontSize']).
element_scrollTo – Desplaza un componente scroll-view a una posición específica (x, y).
element_getAttributes – Obtiene los valores de los atributos de un elemento, el parámetro names es una matriz de nombres de atributos (como ['class', 'id', 'data-index']).
element_getBoundingClientRect – Obtiene información del rectángulo delimitador del elemento en relación con la ventana gráfica (left, top, width, height, right, bottom), considerando transformaciones CSS (actualmente solo admite selectores de ID y clase).
Cada herramienta acepta un bloque connection opcional para sobrescribir los valores predeterminados del entorno (ruta del proyecto, ruta del CLI, punto final WebSocket, etc.).
Antes de conectar, habilite la automatización en las Herramientas de Desarrollo de WeChat (Configuración → Configuración de seguridad → Puerto de servicio).
Se recomienda llamar primero a mp_ensureConnection para verificar la conexión y ver los detalles del sistema/página.
Usar WEAPP_AUTOCLOSE=true es adecuado para interacciones únicas sin estado.
Use siempre rutas absolutas al navegar (comenzando con /): /pages/mine/mine.
Use switchTab para páginas de la barra de pestañas (tabBar) y navigateTo para páginas normales.
Al operar con componentes personalizados, hay dos métodos:
innerSelector (recomendado)Aplicable a herramientas como element_tap, element_input, element_getWxml, etc.:
{
"selector": "#my-component",
"innerSelector": ".inner-button"
}selector: Selector del componente personalizado.
innerSelector: Selector del elemento dentro del componente.
Aplicable a element_getInnerElement y element_getInnerElements:
{
"selector": "#my-component",
"targetSelector": ".inner-button"
}page_waitElement no es aplicable a elementos dentro de componentes personalizados. Utilice page_waitTimeout junto con herramientas de consulta de elementos para realizar comprobaciones de sondeo.
Cuando se configura WEAPP_AUTOLAUNCH=true, el servidor MCP puede detectar e iniciar automáticamente las Herramientas de Desarrollo de WeChat:
Detección automática de puerto: Detecta si hay un servicio ejecutándose en el puerto 9420.
Iniciar si no hay servicio: Si el puerto no está ocupado, llama automáticamente al CLI para iniciar las herramientas de desarrollo.
Selección de proyecto:
Si hay una configuración de proyecto predeterminada, se usa automáticamente.
Si no hay un proyecto predeterminado, se listan automáticamente los proyectos recientes para elegir.
Admite ingresar el número de proyecto (por ejemplo, 1) o la ruta completa.
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": ["-y", "weapp-dev-mcp"],
"env": {
"WEAPP_AUTOLAUNCH": "true",
"WEAPP_PROJECT_PATH": "D:\\path\\to\\your\\project"
}
}
}
}En la primera conexión, se detecta WEAPP_AUTOLAUNCH=true.
Se comprueba si hay un servicio en el puerto 9420.
Si no hay servicio, se inician automáticamente las herramientas de desarrollo (usando cli.bat auto --project <path> --auto-port 9420).
Se esperan 45 segundos para que las herramientas de desarrollo estén listas.
Se establece la conexión WebSocket.
Las conexiones posteriores reutilizan automáticamente la conexión existente.
Sugerencia: Después de configurar el proyecto predeterminado con
mp_setDefaultProject, no es necesario volver a seleccionar el proyecto en la próxima conexión.
调用组件实例指定方法，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing behavioral traits like destructiveness, side effects, or failure behavior. The brevity leaves the agent guessing about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. It avoids unnecessary words, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested connection object, no output schema), the description is severely incomplete. It omits crucial context such as what methods are valid, how args should be structured, and what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter beyond the schema itself. Parameters like connection, method, args, and innerSelector are left entirely undocumented, forcing reliance on the raw schema which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'call' and the resource 'component instance specified method', and adds the constraint 'only custom components can be used', which distinguishes it from sibling tools like page_callMethod and other element manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by noting that it is only for custom components, implying it should not be used for native components. However, it does not mention alternatives or when not to use this tool, lacking explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的特性值。names 为特性名数组（如 ['class', 'id', 'data-index']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose performance traits, error behavior (e.g., missing attribute handling), authentication needs, or side effects. Only the basic operation is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose and parameter semantics with no redundancy. Front-loaded with the action. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested connection object, no output schema), the description is insufficient. It omits connection configuration, return value format, and typical usage patterns, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'names' parameter (array of attribute names) but ignores other critical parameters like 'selector' (required) and 'innerSelector'. With schema description coverage at 0%, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves attribute values ('获取元素的特性值') and provides an example for the 'names' parameter. It distinguishes from sibling tools like 'element_getStyles' by focusing on attributes, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'element_getData' or 'element_getStyles'. No exclusion criteria or context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素相对于视口的边界矩形信息（left、top、width、height、right、bottom）。此方法返回的是考虑 CSS transform 变换后的实际渲染尺寸和位置。支持跨组件查询：若需获取自定义组件内部元素，可将 selector 设为组件选择器，innerSelector 设为内部元素选择器。注意：目前仅支持 ID 选择器、类选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately covers behavioral traits: it returns bounding rect after applying CSS transforms, supports cross-component queries, and notes a limitation (only ID and class selectors currently supported). It does not describe error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences that front-load the main purpose. Each sentence adds useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields and mentions a key behavior (CSS transform). However, it does not cover the 'connection' parameter, error scenarios, or what happens if the element is not found. This limits completeness for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'selector' and 'innerSelector' but completely omits the 'connection' parameter, which is a complex nested object. This leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns bounding rectangle information (left, top, width, height, right, bottom) relative to the viewport, considering CSS transforms. It differentiates from sibling tools by specifying the exact geometric data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case for cross-component queries using innerSelector but does not explicitly advise when to use this tool over alternatives or when not to use it. No sibling comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取组件实例渲染数据，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or error conditions. It only implies a read operation but lacks explicit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose efficiently without waste. However, it could include more detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested object, 4 parameters) and no output schema, the description is insufficient. It does not explain parameters, output, or behavior, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the use or meaning of any parameters (connection, selector, innerSelector, path). This leaves the agent without guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets component instance rendering data and specifies it is only for custom components, which helps differentiate it from sibling tools. However, 'rendering data' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint (only custom components) but no guidance on when to use this tool versus alternatives like element_getAttributes or element_getStyles. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素，相当于 element.$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions the withWxml option for outerWxml but does not state whether the operation is read-only, requires permissions, has side effects, or what happens if elements are not found. The behavioral profile is severely incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but it is under-specified rather than concise. It lacks front-loading of critical information and leaves important gaps. Every sentence should earn its place, but here the first sentence is ambiguous and the second only covers one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, includes a nested connection object, and has no output schema, the description is woefully incomplete. It fails to explain the core logic of how the selectors work together, the return format, or any edge cases. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only explains the withWxml parameter, leaving selector, innerSelector, and targetSelector completely unexplained. The nested connection object is also not described. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'get element within element range' but does not clarify how the three selectors (selector, innerSelector, targetSelector) relate. The analogy to element.$(selector) is misleading as it suggests only one selector. The purpose is vague and leaves ambiguity about what exactly the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools like element_getInnerElements or element_getElement. There is no mention of prerequisites, context, or alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素数组，相当于 element.$$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns an array of elements and can optionally include outerWxml. However, no annotations exist, and the description omits any side effects, required permissions, error conditions, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey the core function and an optional feature. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema (5 parameters, including a nested connection object) and no output schema, the description is insufficient. It does not explain the connection parameter, the meaning of innerSelector, or how to use the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only explains the withWxml parameter. The roles of selector, innerSelector, and targetSelector are not clarified, leaving ambiguity for the agent. The required parameters selector and targetSelector are mentioned in schema but not explained in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an array of inner elements, analogous to element.$$(selector), and mentions the optional withWxml parameter. However, it does not explicitly differentiate from the sibling tool element_getInnerElement (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like element_getInnerElement, element_getAttributes, or other element methods. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的样式值。names 为样式名数组（如 ['color', 'fontSize', 'backgroundColor']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose any behavioral traits such as whether it returns computed styles, possible side effects, or error conditions. The description is minimal and does not help the agent understand tool behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it lacks structure. It front-loads the purpose but omits important details. For a single-sentence description, it is efficient but not comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested connection object, no output schema), the description is incomplete. It does not explain how to use the 'connection' parameter, what the return value looks like, or any constraints. The agent would lack sufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains one of four parameters ('names') with an example. It does not explain 'selector', 'innerSelector', or the complex 'connection' object. The agent would need to infer the meaning from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取元素的样式值' (get element style values). It specifies the 'names' parameter as an array of style names, differentiating from sibling tools like element_getAttributes or element_getData. However, it does not explicitly distinguish from other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., element_getAttributes for attributes). It does not mention prerequisites or typical use cases. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素 WXML。默认获取内部 WXML(element.wxml())，设置 outer 为 true 可获取包含元素本身的 WXML(element.outerWxml())。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| outer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states it gets WXML but does not mention whether it is read-only, idempotent, or what happens on errors (e.g., element not found). No side effects or prerequisites are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loads the main purpose. However, it sacrifices necessary detail for brevity, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (one required nested object), no output schema, and no annotations, the description is severely incomplete. It fails to cover connection setup, selector semantics, and return format, leaving the agent with inadequate information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'outer' and its effect. 'connection', 'selector', and 'innerSelector' are not explained, leaving the agent without understanding of their roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves element WXML, distinguishing between inner and outer WXML via the 'outer' parameter. This differentiates it from sibling tools like element_getData or element_getStyles, which retrieve different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., element_getAttributes, element_getBoundingClientRect). The description only explains the 'outer' option but provides no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
向指定元素输入文本。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only says 'input text' without indicating whether the tool replaces existing content, appends, or triggers events. There is no mention of side effects, permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but it is under-specified for a tool with 4 parameters, nested objects, and no annotations. Conciseness should not come at the cost of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, no output schema, no annotations), the description is severely incomplete. It fails to address parameter roles, behavioral nuances, or usage context, leaving a significant knowledge gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not describe any parameter, including key ones like 'selector', 'value', or the complex 'connection' object. The agent is left to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (input text) and target (specified element), making the tool's primary purpose understandable. However, it does not differentiate from sibling tools like element_setData or element_tap, which could also involve modifying element state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as element_setData or page_callMethod. The description lacks any context about prerequisites, when input is appropriate, or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
滚动 scroll-view 组件到指定位置。仅适用于 scroll-view 组件。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool scrolls to a position and applies only to scroll-view, but lacks details on prerequisites (e.g., connection), side effects, or behavior if the element is not scrollable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. However, it may be too concise given the complex input schema, but it remains clear and free of unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information on prerequisites (e.g., connection setup), return values, and whether scrolling is animated. Given the schema with many parameters and no output schema, this is incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds very little parameter context. It does not explain key parameters like selector, innerSelector, x, y, or the connection object. The agent would need to guess their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls a scroll-view component to a specified position, and specifies it only applies to scroll-view components. This distinguishes it from sibling tools like element_tap or element_callMethod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is only for scroll-view components, guiding when to use it. However, it does not mention when not to use it or suggest alternatives for non-scroll-view elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
设置组件实例渲染数据，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It omits effects like overwriting existing data, required authentication (connection parameter), or error behavior. Only 'only custom components' is stated, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and includes essential restriction, but lacks deeper structure. Could be expanded to cover parameters and behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, nested objects, no annotations, and no output schema, the description is too sparse. It ignores connection setup, selector semantics, and output handling. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description only hints at the 'data' parameter ('rendering data'). Parameters like selector, innerSelector, and connection are not explained. Minimal value added over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets component instance rendering data and explicitly notes it is only for custom components, distinguishing it from page_setData. Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is setting data for custom components, but no when-not-to-use or alternatives are mentioned. The sibling page_setData exists, but the description does not compare them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 CSS 选择器模拟点击 WXML 元素。支持 [index=N] 语法选择第 N 个元素。如需点击自定义组件内部的元素，请使用 innerSelector 参数：selector 设为组件 ID 选择器(如 #my-component)或标签选择器，innerSelector 设为组件内部元素的选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| waitMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It mentions simulating a click but does not specify whether it waits for visibility, the type of click (tap/long press), or any side effects. The waitMs parameter's role is unclear. This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences in Chinese, front-loading the main purpose and then adding details about index syntax and innerSelector. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a complex nested connection parameter, the description lacks details on waitMs behavior, connection requirements, and return values. It covers selector usage well but omits prerequisites and behavioral context, leaving the tool incompletely specified for autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for selector (CSS selector with index syntax) and innerSelector (component-inside-element), explaining their relationship. However, it does not explain connection or waitMs, leaving those parameters unclear. It partially offsets the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates clicking a WXML element via CSS selector, distinguishing it from other element_* tools like element_input. It also details the [index=N] syntax and innerSelector for custom components, which clarifies its specific functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use innerSelector (for custom components) and how to set parameters. However, it does not compare to alternatives like element_callMethod or page_getElement, nor does it state when not to use this tool. Still, it provides good contextual guidance for its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用微信小程序 API 方法，（如 wx.pageScrollTo）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that a connection via the 'connection' parameter is required, nor any side effects, error handling, or rate limits. The example is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It does not front-load critical information like required parameters or return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters including a nested object, no output schema, no annotations), the description is severely incomplete. It omits prerequisites, return values, error handling, and how to use the 'connection' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning to parameters. It only mentions 'method' implicitly and ignores 'connection' and 'args', failing to explain their roles or requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls WeChat Mini Program API methods like `wx.pageScrollTo`, indicating a specific verb and resource. It distinguishes from sibling tools like `mp_navigate` which are for specific operations, but the description is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as `mp_navigate` or `mp_screenshot`. The description lacks context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前页面的信息，包括路径、查询参数、尺寸和滚动位置。通常在 mp_ensureConnection 成功后立即调用，用于确认当前页面。withData 为 true 时额外返回页面数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| withData | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It truthfully states the tool retrieves information without implying side effects, though it could explicitly state it is a read-only operation. The optional return of page data with withData is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no filler, and front-loads the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex nested parameter and no output schema, the description is incomplete. It omits details about the connection parameter and what the return data contains (beyond path, query, size, scroll). The usage context helps, but key aspects are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains the withData parameter ('when true, additionally returns page data') but provides no explanation for the complex 'connection' nested object with many properties, leaving its semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves current page information including path, query parameters, size, and scroll position. It distinguishes itself from siblings like page_getData or page_callMethod by focusing on the page's current state. The mention of typical usage after mp_ensureConnection further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends calling this tool after mp_ensureConnection succeeds, providing clear usage context. It also explains when to set withData=true for additional data. However, it does not mention when not to use this tool or alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查小程序自动化会话是否就绪。先调用这个工具，再调用 mp_screenshot、page_* 或 element_* 工具。若失败，优先用 reconnect=true 重试一次；若返回项目选择提示，则传 projectSelection。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| reconnect | No | ||
| projectSelection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses the tool's main behavior (checking readiness) and failure modes (retry with reconnect, project selection handling). It lacks details on side effects or what happens on success, but the disclosed behaviors are sufficient for basic usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, the first clearly stating purpose and prerequisite order, the second detailing failure handling. No redundant information, front-loaded, and efficiently communicates key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested connection object, no output schema, no annotations), the description is incomplete. It does not explain the connection parameters or what 'ready' means in terms of output. The tool is critical for session setup but leaves significant ambiguity about its inputs and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions reconnect and projectSelection, but the main connection object (with 15 properties) is not explained. The agent gets partial semantics for two parameters, but the core input remains opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the mini-program automation session is ready, using the verb '检查' (check) on the resource '会话' (session). It further differentiates itself by specifying it's a prerequisite for screenshot, page_, and element_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first before others, and provides specific failure handling: retry with reconnect=true for general failure, and pass projectSelection if a project selection prompt appears. This gives clear when-to-use and alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小程序控制台日志。可选择在获取后清空日志。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| clear | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states get logs and optionally clear, but does not explain side effects of clearing, connection prerequisites, or behavior in edge cases. The complex 'connection' parameter is left undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. However, could be expanded with a brief note on connection prerequisites or return format without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complex nested 'connection' object (16 sub-properties) and no output schema, the description provides zero context on connection setup, expected response, or log contents. Inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). Description only mentions 'logs' and 'clear' but does not explain the 'connection' object's properties or the exact effect of 'clear' (e.g., clears logs permanently?). User must infer from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb '获取' (Get) and resource '小程序控制台日志' (mini program console logs), with optional clearing. This distinguishes it from sibling tools which cover other mini program operations like calling wx, navigating, screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance when to use this tool versus others, no precondition hints (e.g., requires connection), and no exclusion scenarios. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出微信开发者工具中的最近项目，方便在 mp_ensureConnection 返回项目选择提示后继续选择项目。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it lists recent projects, without mentioning side effects, permissions, or output format. For a tool that presumably performs a read operation, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and usage context without any redundant information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is minimally complete: it explains what the tool does and when to use it. However, it lacks details about the output format (e.g., list of project names or IDs) and any constraints, which could be useful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. With 0 parameters, the baseline is 4. The description adds context by specifying the scope as 'recent projects', which is helpful but not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent projects in WeChat Developer Tools, using the verb 'list' and specifying the resource as 'recent projects'. It provides a usage context (after mp_ensureConnection returns a project selection prompt), but does not explicitly differentiate from sibling tools like mp_setDefaultProject or mp_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific usage scenario: using this tool after mp_ensureConnection returns a project selection prompt. However, it does not provide explicit guidance on when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
截取当前小程序视口的截图。需要已有活动会话；若提示没有活动会话，请先调用 mp_ensureConnection。默认返回内联图片，或保存到文件路径。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that a screenshot is captured, active session is required, and output defaults to inline image or file save. However, it does not detail potential side effects or error conditions beyond the session prompt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is first, followed by prerequisite and output behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested connection parameter, no annotations, no output schema), the description covers the core purpose and usage context but leaves the connection parameter unexplained. It references mp_ensureConnection but does not fully describe the connection setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'path' parameter (save to file) but provides no explanation for the complex 'connection' parameter. Users must rely on external knowledge or sibling tool mp_ensureConnection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'take a screenshot of the current mini-program viewport' (specific verb and resource). It distinguishes itself from siblings by focusing on screenshot capture, while other tools like mp_currentPage retrieve page info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the prerequisite of an active session and directs users to call mp_ensureConnection if none exists. This provides clear when-to-use and alternative step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
设置默认的小程序项目路径，设置后下次连接会优先使用该项目。通常用于修复项目选择失败后的后续重试。
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that setting the default affects the next connection, adding behavioral context beyond the absent annotations. However, it does not mention potential side effects, permissions, or reversibility, limiting full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and use case, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers purpose and typical usage scenario, but misses details on return values, error states, or prerequisites. It is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 0% description coverage, and the description does not mention the parameter or its intended use, providing no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'default mini-program project path', and distinguishes its purpose from sibling tools by specifying it is used for retrying after project selection failure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'usually used for retry after project selection failure.' It implies when to use but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用当前页面实例上暴露的方法。参数可以作为数组提供。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action (call a method) and that args can be an array, but does not disclose side effects, error behavior (e.g., unknown method), or any requirements like a valid connection. This is insufficient for zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the purpose. However, given the complexity of the tool (many schema properties), it is under-specified. Every sentence earns its place but more structure (e.g., listing important connection options) would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with a nested connection object and three parameters, yet the description provides almost no additional context beyond a one-line summary. There is no output schema, so the description should explain return values or behavior, which it does not. The description is far from complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the three parameters (connection, method, args). It only mentions that 'args can be provided as an array', which is already evident from the schema. The complex 'connection' object is completely unexplained, and the 'method' field is not elaborated. With 0% coverage, the description should compensate heavily but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'call' and the resource 'methods exposed on the current page instance'. It is not a tautology and provides a specific action. However, it does not differentiate from sibling tool 'element_callMethod', which calls methods on elements, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'element_callMethod' or when not to use it. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前页面的数据对象，可选择指定子数据路径。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'get', implying a read operation, but does not disclose any behavioral traits such as side effects, permissions, or rate limits. The description lacks explicit safety or state-change information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. It is efficient in length, but could be more structured to cover multiple aspects (e.g., parameter explanation, usage context). The conciseness is good, but sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested connection object, no annotations, no output schema), the description is severely incomplete. It does not address the critical connection parameter, nor does it provide any context about return values, prerequisites, or the overall workflow. The agent lacks essential information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The description briefly explains the 'path' parameter as a sub-data path, but completely omits explanation of the 'connection' parameter, which is a complex nested object with many subproperties. This leaves the agent uninformed about the primary parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current page's data object, with an optional sub-path. It specifically mentions 'current page', distinguishing it from sibling element-level tools like element_getData. The verb 'get' and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for page data, but does not mention when not to use it or suggest alternatives like element_getData for element-level data. The context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素，相当于 page.$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains returned fields and the withWxml option, but omits critical details such as the need for a connection, error handling (e.g., element not found), and whether the tool waits or returns immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a clear purpose: stating equivalency, listing returns and toggles, and noting index syntax. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It fails to cover connection requirements, return value when element is missing, or distinguish from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for selector (CSS selector, index syntax) and withWxml (returns outerWxml), but provides no information about the required connection object or the optional innerSelector parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool gets a page element by selector, equivalent to page.$(), and lists returned fields. However, it does not explicitly differentiate from the sibling tool page_getElements, which likely returns multiple elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a selector and element information is needed, but it does not provide explicit guidance on when to use this tool instead of alternatives like page_getElements or other element tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素数组，相当于 page.$$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return structure and the effect of withWxml, and mentions [index=N] syntax. However, it does not explain behavior on no matches, error handling, or the connection parameter's role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with the main action, and each sentence adds value. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description explains return fields and the withWxml option, but does not cover the connection parameter or behavior when selector matches nothing. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains selector and withWxml well, but completely omits the connection parameter, which is a complex nested object. Two out of three parameters are covered, but the missing one is significant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets an array of page elements via selector, equivalent to page.$$(), and lists returned fields. It distinguishes from sibling tools like page_getElement by specifying it returns multiple elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multiple elements via the 'equivalent to page.$$' phrase and mentions the withWxml option. However, it does not explicitly state when not to use or provide alternatives, though sibling names offer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 setData 更新当前页面的数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states that it updates data, with no details on side effects, permissions, or error conditions. No annotations provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too brief, missing essential context for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, output schema, or parameter descriptions, the description is severely incomplete for a tool that modifies page data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description adds no information about parameters. The required 'data' parameter remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and target (current page's data), but lacks differentiation from sibling tools like element_setData or page_getData.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like element_setData or page_getData, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
等待指定选择器的元素出现在页面上。支持 [index=N] 语法选择第 N 个元素。增强版：增加了超时和重试间隔参数。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| timeout | No | ||
| retryInterval | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions timeout and retry interval, but does not specify behavior on failure (e.g., timeout error), return value, or side effects. The description is insufficient for an agent to fully predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences. It front-loads the primary purpose and then adds secondary features. No redundant information. However, it could be slightly more structured by separating core purpose from enhancements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex 'connection' parameter, no output schema, and no annotations, the description is incomplete. It omits explanation of the connection object, error handling, and return values. The description only covers selector semantics and basic retry/timeout, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the selector parameter by explaining the [index=N] syntax. It also states timeout and retry interval are 'enhanced' parameters. However, the complex 'connection' object is left unexplained, and other parameters lack context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for an element specified by a selector to appear on the page. It mentions support for [index=N] syntax, which adds clarity about selecting specific elements. However, it does not explicitly distinguish this tool from siblings like page_waitTimeout or page_getElement, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, common use cases, or when not to use it. The sibling tools suggest broader workflow, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
等待指定的毫秒数。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| milliseconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action of waiting and does not cover whether the wait is blocking, cancellable, or how it interacts with page lifecycle. No additional traits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It does not front-load key information or use formatting to aid readability. While efficient, it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple parameters (including a nested connection object) and no annotations or output schema, the description is severely incomplete. It omits return behavior, error conditions, and prerequisites, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for either parameter. The 'milliseconds' parameter is somewhat self-explanatory from its name, but the complex 'connection' object is completely undocumented. The description fails to provide any semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a specified number of milliseconds. The name 'page_waitTimeout' implies time-based waiting, and the description confirms the unit. However, it does not differentiate from sibling tools like page_waitElement, which wait for a condition rather than a fixed duration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios where a fixed delay is preferable to conditional waits, nor does it provide context on prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.4element_callMethodelement_getAttributeselement_getBoundingClientRectelement_getDataelement_getInnerElementelement_getInnerElementselement_getStyleselement_getWxmlelement_inputelement_scrollToelement_setDataelement_tapmp_callWxmp_currentPagemp_ensureConnectionmp_getLogsmp_listProjectsmp_navigatemp_screenshotmp_setDefaultProjectpage_callMethodpage_getDatapage_getElementpage_getElementspage_setDatapage_waitElementpage_waitTimeoutv0.1.6element_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutv1.0.0element_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElements2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getSize2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getWxml2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_input2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_tap2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_callWx2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_ensureConnection2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_getLogs2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_navigate2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_screenshot2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitTimeout2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutScored across 27 tools
Each tool targets a distinct action within its category (element, mp, page). Within each group, operations like getAttributes, getBoundingClientRect, getData are clearly different. No two tools overlap in purpose.
All tools follow a consistent pattern: category_verbNoun (e.g., element_tap, mp_navigate, page_setData). Underscore separation and camelCase for the verb+noun are uniform across all 27 tools.
With 27 tools, the count is on the higher side but well-justified by the broad scope (element manipulation, page control, and mini-program API calls). It's reasonably scoped for a comprehensive development assistant.
The tool set covers core operations: element querying/interaction, page data management, and mini-program API invocation. Minor gaps like gesture simulation or file operations exist, but the essential CRUD and lifecycle actions are present.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Give your AI agents the tools to build, manage, and run automation workflows.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
