Skip to main content
Glama
yfmeii

WeChat Mini Program Dev MCP

by yfmeii

element_tap

Simulate clicking WXML elements in WeChat mini programs using CSS selectors. Click custom component elements by specifying innerSelector for precise targeting.

Instructions

通过 CSS 选择器模拟点击 WXML 元素。如需点击自定义组件内部的元素,请使用 innerSelector 参数:selector 设为组件 ID 选择器(如 #my-component),innerSelector 设为组件内部元素的选择器。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
connectionNo
selectorYes
innerSelectorNo
waitMsNo

Implementation Reference

  • Full tool definition including the execute handler for the 'element_tap' tool. It parses arguments, resolves the target element using selector and optional innerSelector, performs a tap action, optionally waits, and returns a confirmation message.
    function createTapElementTool(manager: WeappAutomatorManager): AnyTool {
      return {
        name: "element_tap",
        description: "通过 CSS 选择器模拟点击 WXML 元素。如需点击自定义组件内部的元素,请使用 innerSelector 参数:selector 设为组件 ID 选择器(如 #my-component),innerSelector 设为组件内部元素的选择器。",
        parameters: tapElementParameters,
        execute: async (rawArgs, context: ToolContext) => {
          const args = tapElementParameters.parse(rawArgs ?? {});
          const waitMs = args.waitMs;
          return manager.withPage(
            context.log,
            { overrides: args.connection },
            async (page) => {
              const element = await resolveElement(
                page,
                args.selector,
                args.innerSelector
              );
    
              await element.tap();
              await waitOnPage(page, waitMs);
    
              return toTextResult(
                `已点击元素 "${args.selector}"${args.innerSelector ? ` -> "${args.innerSelector}"` : ""}${waitMs ? ` 并等待 ${waitMs}ms` : ""}。`
              );
            }
          );
        },
      };
    }
  • Zod schema defining the input parameters for the 'element_tap' tool: selector (required), innerSelector (optional), and waitMs (optional).
    const tapElementParameters = connectionContainerSchema.extend({
      selector: z.string().trim().min(1),
      innerSelector: z.string().trim().min(1).optional(),
      waitMs: z.coerce.number().int().nonnegative().optional(),
    });
  • The 'element_tap' tool is registered as the first tool in the array returned by createElementTools.
    export function createElementTools(
      manager: WeappAutomatorManager
    ): AnyTool[] {
      return [
        createTapElementTool(manager),
        createInputTextTool(manager),
        createCallElementMethodTool(manager),
        createGetElementDataTool(manager),
        createSetElementDataTool(manager),
        createGetInnerElementTool(manager),
        createGetInnerElementsTool(manager),
        createGetElementSizeTool(manager),
        createGetElementWxmlTool(manager),
      ];
    }
  • src/tools.ts:7-13 (registration)
    createTools incorporates the element tools (including element_tap) into the full tools array.
    export function createTools(manager: WeappAutomatorManager): AnyTool[] {
      return [
        ...createApplicationTools(manager),
        ...createPageTools(manager),
        ...createElementTools(manager),
      ];
    }
  • src/index.ts:17-17 (registration)
    Final registration of all tools, including element_tap, to the FastMCP server.
    server.addTools(createTools(manager));
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool simulates clicking and provides guidance for custom components, but doesn't describe what happens after the click (e.g., page navigation, state changes, error handling), whether it waits for element visibility, what permissions are needed, or any side effects. For a UI automation tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded. The first sentence states the core purpose clearly. The second sentence provides essential additional guidance for a specific use case. There is zero wasted language, and both sentences earn their place by adding distinct value.

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

Completeness2/5

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

Given the complexity (4 parameters including a nested connection object with 11 sub-properties), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It covers basic usage for selector/innerSelector but ignores the critical connection parameter entirely and provides no information about return values, error conditions, or behavioral expectations. For an automation tool with this level of complexity, the description should do much more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds meaningful context for selector and innerSelector parameters by explaining their relationship for custom components. However, it doesn't mention the connection parameter (which appears complex with 11 sub-properties) or waitMs at all. The description partially compensates but leaves most parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: '通过 CSS 选择器模拟点击 WXML 元素' (simulate clicking WXML elements via CSS selector). It specifies the verb ('模拟点击' - simulate click), resource ('WXML 元素' - WXML elements), and mechanism ('CSS 选择器' - CSS selector). It also distinguishes from siblings by mentioning the special case for custom components, which is unique among the listed sibling tools.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the innerSelector parameter: '如需点击自定义组件内部的元素,请使用 innerSelector 参数' (if you need to click elements inside custom components, use the innerSelector parameter). It gives specific guidance for a particular use case but doesn't explicitly state when NOT to use this tool versus alternatives like element_callMethod or page_waitElement, nor does it mention prerequisites like needing an established connection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yfmeii/weapp-dev-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server