FastMCP 기반의 서버로, miniprogram-automator를 통해 위챗 개발자 도구를 자동화합니다. 이 서버는 AI 어시스턴트가 미니 프로그램 페이지를 탐색, 검사 및 조작할 수 있도록 MCP 도구를 제공합니다. playwright-mcp와 유사하지만 위챗 생태계에 맞게 최적화되었습니다.
명령줄 액세스(cli / cli.bat)를 지원하는 위챗 개발자 도구가 설치되어 있어야 합니다.
로컬에 Node.js 18+ 및 npm이 설치되어 있어야 합니다.
개발자 도구에서 열 수 있는 미니 프로그램 프로젝트가 있어야 합니다.
Related MCP server: weapp-agent-mcp
@yfme/weapp-dev-mcp는 npm에 배포되어 있으므로, 일반 사용자는 저장소를 복제하거나 node dist/index.js를 수동으로 실행할 필요가 없습니다.
npx -y @yfme/weapp-dev-mcpnpm install -g @yfme/weapp-dev-mcp
weapp-dev-mcp또는 프로젝트 의존성으로 추가:
npm install --save-dev @yfme/weapp-dev-mcp
npx weapp-dev-mcp본 저장소 내에서 개발하는 경우에만
node dist/index.js를 직접 실행하는 것을 권장합니다. 일반 사용자는 위의 npm 패키지 방식으로 시작하십시오.
Claude Desktop 또는 기타 MCP 클라이언트에서 이 서버를 사용하려면 설정 파일에 다음을 추가하십시오:
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": [
"-y",
"@yfme/weapp-dev-mcp"
],
"env": {
"WEAPP_WS_ENDPOINT": "ws://localhost:9420"
}
}
}
}Claude Code를 사용하여 MCP 도구를 호출할 때 도구 호출 권한 승인 요청이 발생하면, MCP와 위챗 개발자 도구 간의 연결 상태가 끊길 수 있습니다. 콘솔 출력은 연결 상태에 크게 의존하므로 로그를 연속적으로 가져올 수 없게 됩니다. 따라서 권한을 수동으로 추가하는 것을 권장합니다:
프로젝트 디렉토리에 .claude/settings.local.json 파일을 생성하거나 기존 파일에 다음 내용을 추가하면 확인 절차 없이 도구를 직접 호출할 수 있습니다. 필요에 따라 승인할 도구를 추가하십시오:
{
"permissions": {
"allow": [
"mcp__weapp-dev-mcp__mp_ensureConnection",
"mcp__weapp-dev-mcp__mp_navigate",
"mcp__weapp-dev-mcp__mp_screenshot",
"mcp__weapp-dev-mcp__mp_callWx",
"mcp__weapp-dev-mcp__mp_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"
]
}
}주의: 도구 이름 형식은
mcp__<서버 이름>__<도구 이름>입니다. 서버 이름이 MCP 설정의 이름과 일치하는지 확인하십시오.
MCP 서버를 사용하기 전에 위챗 개발자 도구를 시작하고 WebSocket 서비스를 활성화해야 합니다.
💡 시작하기 전에:
위챗 개발자 도구를 엽니다.
**설정(Settings) → 보안 설정(Security Settings) → 서비스 포트(Service Port)**로 이동합니다.
**"HTTP 디버깅(HTTP Debugging)"**과 **"자동화 테스트(Automation Test)"**를 켭니다.
명령줄을 사용하여 시작
명령줄을 사용하여 위챗 개발자 도구를 시작하고 WebSocket 서비스를 자동으로 활성화합니다:
macOS/Linux:
/Applications/wechatwebdevtools.app/Contents/MacOS/cli auto --project /path/to/your/project --auto-port 9420Windows:
"C:\Program Files (x86)\Tencent\微信web开发者工具\cli.bat" auto --project C:\path\to\your\project --auto-port 9420설명:
--project 매개변수는 미니 프로그램 프로젝트 디렉토리 경로를 지정합니다 (실제 경로로 교체하십시오).
--auto-port 매개변수는 WebSocket 서비스 포트를 지정합니다 (기본값 9420).
⚠️ 경고 샌드박스 메커니즘으로 인해 일부 클라이언트는 MCP가 프로젝트 디렉토리 외부의 위챗 개발자 도구 CLI에 액세스하는 것을 허용하지 않으므로, 여기서는 WebSocket 서비스를 사용하는 방법만 설명합니다.
환경 변수를 통해 자동화 도구가 위챗 개발자 도구에 연결되는 방식을 제어합니다:
변수 | 설명 |
| 【권장】 실행 중인 개발자 도구 WebSocket 엔드포인트. 설정 시 서버는 새 인스턴스를 시작하는 대신 |
| 위챗 개발자 도구 CLI 경로 (기본 경로가 유효하면 선택 사항). |
|
|
| 개발자 도구 시작 시 선호하는 포트 (사용 가능한 포트로 대체됨). |
| 시작 시간 초과 (밀리초, 기본값 30000). |
| 자동 로그인을 위해 |
| 시작 시 |
| 시작 시 |
| 시작 시 추가 CLI 매개변수 (공백으로 구분). |
| 개발자 도구 프로세스로 전달될 작업 디렉토리. |
|
|
|
|
| 시작 시간 초과 (밀리초, 기본값 45000) |
| 연결 시간 초과 (밀리초, 기본값 45000) |
| 미니 프로그램 프로젝트 경로 (선택 사항) |
주의: 개발자 도구를 시작(
launch모드)할 때, MCP 도구 매개변수를 통해 미니 프로그램 프로젝트 디렉토리를 제공해야 합니다. 작업 수행 전connection.projectPath를 통해 제공하십시오 (예:mp_ensureConnection). 이 값은 설정되면 후속 호출에서 유지됩니다.
도구 호출은 connection 객체를 통해 이러한 기본값 대부분을 덮어쓸 수 있습니다.
mp_ensureConnection – 자동화 세션 준비 확인; 강제 재연결 또는 연결 설정 덮어쓰기 가능
mp_navigate – 미니 프로그램 내 탐색 (navigateTo, redirectTo, reLaunch, switchTab, navigateBack 지원)
mp_screenshot – 스크린샷 캡처 및 반환 (또는 디스크에 저장)
mp_callWx – 위챗 미니 프로그램 API 메서드 호출 (예: wx.showToast)
mp_getLogs – 미니 프로그램 콘솔 로그 가져오기, 가져온 후 삭제 옵션 제공
mp_currentPage – 현재 페이지 정보 가져오기 (경로, 쿼리 매개변수, 크기, 스크롤 위치), withData가 true일 경우 페이지 데이터 추가 반환
mp_listProjects – 위챗 개발자 도구의 최근 프로젝트 목록 표시 (프로젝트 디렉토리 선택 용이)
mp_setDefaultProject – 기본 미니 프로그램 프로젝트 경로 설정, 설정 후 다음 연결 시 자동으로 해당 프로젝트 사용
page_getElement – 선택자를 통해 페이지 요소 가져오기, 요소 요약 정보 반환 (tagName, text, value, size, offset); withWxml: true 설정 시 전체 outerWxml 추가 반환; [index=N] 구문을 사용하여 N번째 요소 선택 지원
page_getElements – 선택자를 통해 페이지 요소 배열 가져오기, 각 요소의 요약 정보 반환; withWxml: true 설정 시 각 요소의 전체 outerWxml 추가 반환; [index=N] 구문 지원
page_waitElement – 페이지에 요소가 나타날 때까지 대기 (⚠️ 사용자 정의 컴포넌트 내부 요소에는 적용 불가); [index=N] 구문 지원; 시간 초과 및 재시도 간격 매개변수 추가
page_waitTimeout – 지정된 밀리초만큼 대기
page_getData – 현재 페이지의 데이터 객체 가져오기, 경로 지정 가능 ('user.name'과 같은 중첩 경로 지원)
page_setData – setData를 사용하여 현재 페이지 데이터 업데이트; 데이터가 실제로 업데이트되었는지 확인하는 verify 옵션 추가
page_callMethod – 현재 페이지 인스턴스에 노출된 메서드 호출
element_tap – CSS 선택자를 통해 WXML 요소 클릭 시뮬레이션; [index=N] 구문으로 N번째 요소 선택 지원; x/y 좌표 오프셋 클릭 지원; 안정성 강화: 요소 상호작용 가능 상태 대기, 클릭 후 페이지 경로 변경 자동 확인
element_input – 요소에 텍스트 입력 (input 및 textarea 컴포넌트에 적용)
element_callMethod – 사용자 정의 컴포넌트 인스턴스의 메서드 호출
element_getData – 사용자 정의 컴포넌트 인스턴스의 렌더링 데이터 가져오기
element_setData – 사용자 정의 컴포넌트 인스턴스의 렌더링 데이터 설정
element_getInnerElement – 요소 내부의 요소 가져오기 (element.$(selector)와 동일), 요소 요약 정보 반환; withWxml: true 설정 시 전체 outerWxml 추가 반환
element_getInnerElements – 요소 내부의 요소 배열 가져오기 (element.$$(selector)와 동일), 요소 요약 정보 반환; withWxml: true 설정 시 각 요소의 전체 outerWxml 추가 반환
element_getWxml – 요소 WXML 가져오기 (내부 또는 외부)
element_getStyles – 요소의 CSS 스타일 값 가져오기, names 매개변수는 스타일 이름 배열 (예: ['color', 'fontSize'])
element_scrollTo – scroll-view 컴포넌트를 지정된 위치(x, y)로 스크롤
element_getAttributes – 요소의 속성 값 가져오기, names 매개변수는 속성 이름 배열 (예: ['class', 'id', 'data-index'])
element_getBoundingClientRect – 뷰포트 기준 요소의 경계 사각형 정보(left, top, width, height, right, bottom) 가져오기, CSS transform 변환 고려 (현재 ID 선택자, 클래스 선택자만 지원)
각 도구는 환경 기본값(프로젝트 경로, CLI 경로, WebSocket 엔드포인트 등)을 덮어쓰기 위한 선택적 connection 블록을 허용합니다.
연결 전 위챗 개발자 도구에서 자동화 활성화 (설정 → 보안 설정 → 서비스 포트)
먼저 mp_ensureConnection을 호출하여 연결을 확인하고 시스템/페이지 세부 정보를 확인하는 것을 권장합니다.
WEAPP_AUTOCLOSE=true는 상태가 없는 일회성 상호작용에 적합합니다.
탐색 시 항상 절대 경로를 사용하십시오 ( /로 시작): /pages/mine/mine
tabBar 페이지는 switchTab을, 일반 페이지는 navigateTo를 사용하십시오.
사용자 정의 컴포넌트를 조작할 때는 두 가지 방법이 있습니다:
innerSelector 매개변수 사용 (권장)element_tap, element_input, element_getWxml 등의 도구에 적용 가능:
{
"selector": "#my-component",
"innerSelector": ".inner-button"
}selector: 사용자 정의 컴포넌트의 선택자
innerSelector: 컴포넌트 내부 요소의 선택자
element_getInnerElement 및 element_getInnerElements 도구에 적용 가능:
{
"selector": "#my-component",
"targetSelector": ".inner-button"
}page_waitElement는 사용자 정의 컴포넌트 내부 요소에 적용되지 않습니다. page_waitTimeout과 요소 쿼리 도구를 함께 사용하여 폴링(polling) 방식으로 확인하십시오.
WEAPP_AUTOLAUNCH=true로 설정하면 MCP 서버가 위챗 개발자 도구를 자동으로 감지하고 시작할 수 있습니다:
포트 자동 감지: 9420 포트에서 서비스가 실행 중인지 확인
서비스 미실행 시 시작: 포트가 사용 중이 아니면 CLI를 호출하여 개발자 도구 시작
프로젝트 선택:
기본 프로젝트 설정이 있으면 자동으로 사용
기본 프로젝트가 없으면 최근 프로젝트 목록을 표시하여 선택 유도
프로젝트 번호(예: 1) 또는 전체 경로 입력 지원
{
"mcpServers": {
"weapp-dev": {
"command": "npx",
"args": ["-y", "weapp-dev-mcp"],
"env": {
"WEAPP_AUTOLAUNCH": "true",
"WEAPP_PROJECT_PATH": "D:\\path\\to\\your\\project"
}
}
}
}최초 연결 시 WEAPP_AUTOLAUNCH=true 감지
9420 포트에서 서비스 실행 여부 확인
서비스가 없으면 개발자 도구 자동 시작 (cli.bat auto --project <path> --auto-port 9420 사용)
개발자 도구가 준비될 때까지 45초 대기
WebSocket 연결 수립
후속 연결 시 기존 연결 자동 재사용
팁:
mp_setDefaultProject를 사용하여 기본 프로젝트를 설정하면 다음 연결 시 프로젝트를 다시 선택할 필요가 없습니다.
调用组件实例指定方法，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing behavioral traits like destructiveness, side effects, or failure behavior. The brevity leaves the agent guessing about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. It avoids unnecessary words, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested connection object, no output schema), the description is severely incomplete. It omits crucial context such as what methods are valid, how args should be structured, and what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter beyond the schema itself. Parameters like connection, method, args, and innerSelector are left entirely undocumented, forcing reliance on the raw schema which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'call' and the resource 'component instance specified method', and adds the constraint 'only custom components can be used', which distinguishes it from sibling tools like page_callMethod and other element manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by noting that it is only for custom components, implying it should not be used for native components. However, it does not mention alternatives or when not to use this tool, lacking explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的特性值。names 为特性名数组（如 ['class', 'id', 'data-index']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose performance traits, error behavior (e.g., missing attribute handling), authentication needs, or side effects. Only the basic operation is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose and parameter semantics with no redundancy. Front-loaded with the action. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested connection object, no output schema), the description is insufficient. It omits connection configuration, return value format, and typical usage patterns, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'names' parameter (array of attribute names) but ignores other critical parameters like 'selector' (required) and 'innerSelector'. With schema description coverage at 0%, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves attribute values ('获取元素的特性值') and provides an example for the 'names' parameter. It distinguishes from sibling tools like 'element_getStyles' by focusing on attributes, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'element_getData' or 'element_getStyles'. No exclusion criteria or context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素相对于视口的边界矩形信息（left、top、width、height、right、bottom）。此方法返回的是考虑 CSS transform 变换后的实际渲染尺寸和位置。支持跨组件查询：若需获取自定义组件内部元素，可将 selector 设为组件选择器，innerSelector 设为内部元素选择器。注意：目前仅支持 ID 选择器、类选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately covers behavioral traits: it returns bounding rect after applying CSS transforms, supports cross-component queries, and notes a limitation (only ID and class selectors currently supported). It does not describe error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences that front-load the main purpose. Each sentence adds useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields and mentions a key behavior (CSS transform). However, it does not cover the 'connection' parameter, error scenarios, or what happens if the element is not found. This limits completeness for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'selector' and 'innerSelector' but completely omits the 'connection' parameter, which is a complex nested object. This leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns bounding rectangle information (left, top, width, height, right, bottom) relative to the viewport, considering CSS transforms. It differentiates from sibling tools by specifying the exact geometric data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case for cross-component queries using innerSelector but does not explicitly advise when to use this tool over alternatives or when not to use it. No sibling comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取组件实例渲染数据，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or error conditions. It only implies a read operation but lacks explicit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose efficiently without waste. However, it could include more detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested object, 4 parameters) and no output schema, the description is insufficient. It does not explain parameters, output, or behavior, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the use or meaning of any parameters (connection, selector, innerSelector, path). This leaves the agent without guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets component instance rendering data and specifies it is only for custom components, which helps differentiate it from sibling tools. However, 'rendering data' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint (only custom components) but no guidance on when to use this tool versus alternatives like element_getAttributes or element_getStyles. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素，相当于 element.$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions the withWxml option for outerWxml but does not state whether the operation is read-only, requires permissions, has side effects, or what happens if elements are not found. The behavioral profile is severely incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but it is under-specified rather than concise. It lacks front-loading of critical information and leaves important gaps. Every sentence should earn its place, but here the first sentence is ambiguous and the second only covers one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, includes a nested connection object, and has no output schema, the description is woefully incomplete. It fails to explain the core logic of how the selectors work together, the return format, or any edge cases. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only explains the withWxml parameter, leaving selector, innerSelector, and targetSelector completely unexplained. The nested connection object is also not described. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'get element within element range' but does not clarify how the three selectors (selector, innerSelector, targetSelector) relate. The analogy to element.$(selector) is misleading as it suggests only one selector. The purpose is vague and leaves ambiguity about what exactly the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools like element_getInnerElements or element_getElement. There is no mention of prerequisites, context, or alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在元素范围内获取元素数组，相当于 element.$$(selector)。设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| targetSelector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns an array of elements and can optionally include outerWxml. However, no annotations exist, and the description omits any side effects, required permissions, error conditions, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey the core function and an optional feature. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema (5 parameters, including a nested connection object) and no output schema, the description is insufficient. It does not explain the connection parameter, the meaning of innerSelector, or how to use the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only explains the withWxml parameter. The roles of selector, innerSelector, and targetSelector are not clarified, leaving ambiguity for the agent. The required parameters selector and targetSelector are mentioned in schema but not explained in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an array of inner elements, analogous to element.$$(selector), and mentions the optional withWxml parameter. However, it does not explicitly differentiate from the sibling tool element_getInnerElement (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like element_getInnerElement, element_getAttributes, or other element methods. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素的样式值。names 为样式名数组（如 ['color', 'fontSize', 'backgroundColor']）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose any behavioral traits such as whether it returns computed styles, possible side effects, or error conditions. The description is minimal and does not help the agent understand tool behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it lacks structure. It front-loads the purpose but omits important details. For a single-sentence description, it is efficient but not comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested connection object, no output schema), the description is incomplete. It does not explain how to use the 'connection' parameter, what the return value looks like, or any constraints. The agent would lack sufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains one of four parameters ('names') with an example. It does not explain 'selector', 'innerSelector', or the complex 'connection' object. The agent would need to infer the meaning from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取元素的样式值' (get element style values). It specifies the 'names' parameter as an array of style names, differentiating from sibling tools like element_getAttributes or element_getData. However, it does not explicitly distinguish from other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., element_getAttributes for attributes). It does not mention prerequisites or typical use cases. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取元素 WXML。默认获取内部 WXML(element.wxml())，设置 outer 为 true 可获取包含元素本身的 WXML(element.outerWxml())。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| outer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states it gets WXML but does not mention whether it is read-only, idempotent, or what happens on errors (e.g., element not found). No side effects or prerequisites are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loads the main purpose. However, it sacrifices necessary detail for brevity, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (one required nested object), no output schema, and no annotations, the description is severely incomplete. It fails to cover connection setup, selector semantics, and return format, leaving the agent with inadequate information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'outer' and its effect. 'connection', 'selector', and 'innerSelector' are not explained, leaving the agent without understanding of their roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves element WXML, distinguishing between inner and outer WXML via the 'outer' parameter. This differentiates it from sibling tools like element_getData or element_getStyles, which retrieve different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., element_getAttributes, element_getBoundingClientRect). The description only explains the 'outer' option but provides no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
向指定元素输入文本。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only says 'input text' without indicating whether the tool replaces existing content, appends, or triggers events. There is no mention of side effects, permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but it is under-specified for a tool with 4 parameters, nested objects, and no annotations. Conciseness should not come at the cost of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, no output schema, no annotations), the description is severely incomplete. It fails to address parameter roles, behavioral nuances, or usage context, leaving a significant knowledge gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not describe any parameter, including key ones like 'selector', 'value', or the complex 'connection' object. The agent is left to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (input text) and target (specified element), making the tool's primary purpose understandable. However, it does not differentiate from sibling tools like element_setData or element_tap, which could also involve modifying element state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as element_setData or page_callMethod. The description lacks any context about prerequisites, when input is appropriate, or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
滚动 scroll-view 组件到指定位置。仅适用于 scroll-view 组件。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool scrolls to a position and applies only to scroll-view, but lacks details on prerequisites (e.g., connection), side effects, or behavior if the element is not scrollable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. However, it may be too concise given the complex input schema, but it remains clear and free of unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information on prerequisites (e.g., connection setup), return values, and whether scrolling is animated. Given the schema with many parameters and no output schema, this is incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds very little parameter context. It does not explain key parameters like selector, innerSelector, x, y, or the connection object. The agent would need to guess their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls a scroll-view component to a specified position, and specifies it only applies to scroll-view components. This distinguishes it from sibling tools like element_tap or element_callMethod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is only for scroll-view components, guiding when to use it. However, it does not mention when not to use it or suggest alternatives for non-scroll-view elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
设置组件实例渲染数据，仅自定义组件可以使用。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It omits effects like overwriting existing data, required authentication (connection parameter), or error behavior. Only 'only custom components' is stated, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and includes essential restriction, but lacks deeper structure. Could be expanded to cover parameters and behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, nested objects, no annotations, and no output schema, the description is too sparse. It ignores connection setup, selector semantics, and output handling. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description only hints at the 'data' parameter ('rendering data'). Parameters like selector, innerSelector, and connection are not explained. Minimal value added over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets component instance rendering data and explicitly notes it is only for custom components, distinguishing it from page_setData. Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is setting data for custom components, but no when-not-to-use or alternatives are mentioned. The sibling page_setData exists, but the description does not compare them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 CSS 选择器模拟点击 WXML 元素。支持 [index=N] 语法选择第 N 个元素。如需点击自定义组件内部的元素，请使用 innerSelector 参数：selector 设为组件 ID 选择器(如 #my-component)或标签选择器，innerSelector 设为组件内部元素的选择器。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| waitMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It mentions simulating a click but does not specify whether it waits for visibility, the type of click (tap/long press), or any side effects. The waitMs parameter's role is unclear. This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences in Chinese, front-loading the main purpose and then adding details about index syntax and innerSelector. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a complex nested connection parameter, the description lacks details on waitMs behavior, connection requirements, and return values. It covers selector usage well but omits prerequisites and behavioral context, leaving the tool incompletely specified for autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for selector (CSS selector with index syntax) and innerSelector (component-inside-element), explaining their relationship. However, it does not explain connection or waitMs, leaving those parameters unclear. It partially offsets the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates clicking a WXML element via CSS selector, distinguishing it from other element_* tools like element_input. It also details the [index=N] syntax and innerSelector for custom components, which clarifies its specific functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use innerSelector (for custom components) and how to set parameters. However, it does not compare to alternatives like element_callMethod or page_getElement, nor does it state when not to use this tool. Still, it provides good contextual guidance for its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用微信小程序 API 方法，（如 wx.pageScrollTo）。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that a connection via the 'connection' parameter is required, nor any side effects, error handling, or rate limits. The example is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It does not front-load critical information like required parameters or return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters including a nested object, no output schema, no annotations), the description is severely incomplete. It omits prerequisites, return values, error handling, and how to use the 'connection' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning to parameters. It only mentions 'method' implicitly and ignores 'connection' and 'args', failing to explain their roles or requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls WeChat Mini Program API methods like `wx.pageScrollTo`, indicating a specific verb and resource. It distinguishes from sibling tools like `mp_navigate` which are for specific operations, but the description is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as `mp_navigate` or `mp_screenshot`. The description lacks context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前页面的信息，包括路径、查询参数、尺寸和滚动位置。通常在 mp_ensureConnection 成功后立即调用，用于确认当前页面。withData 为 true 时额外返回页面数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| withData | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It truthfully states the tool retrieves information without implying side effects, though it could explicitly state it is a read-only operation. The optional return of page data with withData is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no filler, and front-loads the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex nested parameter and no output schema, the description is incomplete. It omits details about the connection parameter and what the return data contains (beyond path, query, size, scroll). The usage context helps, but key aspects are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains the withData parameter ('when true, additionally returns page data') but provides no explanation for the complex 'connection' nested object with many properties, leaving its semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves current page information including path, query parameters, size, and scroll position. It distinguishes itself from siblings like page_getData or page_callMethod by focusing on the page's current state. The mention of typical usage after mp_ensureConnection further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends calling this tool after mp_ensureConnection succeeds, providing clear usage context. It also explains when to set withData=true for additional data. However, it does not mention when not to use this tool or alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查小程序自动化会话是否就绪。先调用这个工具，再调用 mp_screenshot、page_* 或 element_* 工具。若失败，优先用 reconnect=true 重试一次；若返回项目选择提示，则传 projectSelection。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| reconnect | No | ||
| projectSelection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses the tool's main behavior (checking readiness) and failure modes (retry with reconnect, project selection handling). It lacks details on side effects or what happens on success, but the disclosed behaviors are sufficient for basic usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, the first clearly stating purpose and prerequisite order, the second detailing failure handling. No redundant information, front-loaded, and efficiently communicates key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested connection object, no output schema, no annotations), the description is incomplete. It does not explain the connection parameters or what 'ready' means in terms of output. The tool is critical for session setup but leaves significant ambiguity about its inputs and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions reconnect and projectSelection, but the main connection object (with 15 properties) is not explained. The agent gets partial semantics for two parameters, but the core input remains opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the mini-program automation session is ready, using the verb '检查' (check) on the resource '会话' (session). It further differentiates itself by specifying it's a prerequisite for screenshot, page_, and element_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first before others, and provides specific failure handling: retry with reconnect=true for general failure, and pass projectSelection if a project selection prompt appears. This gives clear when-to-use and alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小程序控制台日志。可选择在获取后清空日志。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| clear | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states get logs and optionally clear, but does not explain side effects of clearing, connection prerequisites, or behavior in edge cases. The complex 'connection' parameter is left undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. However, could be expanded with a brief note on connection prerequisites or return format without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complex nested 'connection' object (16 sub-properties) and no output schema, the description provides zero context on connection setup, expected response, or log contents. Inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). Description only mentions 'logs' and 'clear' but does not explain the 'connection' object's properties or the exact effect of 'clear' (e.g., clears logs permanently?). User must infer from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb '获取' (Get) and resource '小程序控制台日志' (mini program console logs), with optional clearing. This distinguishes it from sibling tools which cover other mini program operations like calling wx, navigating, screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance when to use this tool versus others, no precondition hints (e.g., requires connection), and no exclusion scenarios. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出微信开发者工具中的最近项目，方便在 mp_ensureConnection 返回项目选择提示后继续选择项目。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it lists recent projects, without mentioning side effects, permissions, or output format. For a tool that presumably performs a read operation, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and usage context without any redundant information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is minimally complete: it explains what the tool does and when to use it. However, it lacks details about the output format (e.g., list of project names or IDs) and any constraints, which could be useful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. With 0 parameters, the baseline is 4. The description adds context by specifying the scope as 'recent projects', which is helpful but not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent projects in WeChat Developer Tools, using the verb 'list' and specifying the resource as 'recent projects'. It provides a usage context (after mp_ensureConnection returns a project selection prompt), but does not explicitly differentiate from sibling tools like mp_setDefaultProject or mp_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific usage scenario: using this tool after mp_ensureConnection returns a project selection prompt. However, it does not provide explicit guidance on when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
截取当前小程序视口的截图。需要已有活动会话；若提示没有活动会话，请先调用 mp_ensureConnection。默认返回内联图片，或保存到文件路径。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that a screenshot is captured, active session is required, and output defaults to inline image or file save. However, it does not detail potential side effects or error conditions beyond the session prompt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is first, followed by prerequisite and output behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested connection parameter, no annotations, no output schema), the description covers the core purpose and usage context but leaves the connection parameter unexplained. It references mp_ensureConnection but does not fully describe the connection setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'path' parameter (save to file) but provides no explanation for the complex 'connection' parameter. Users must rely on external knowledge or sibling tool mp_ensureConnection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'take a screenshot of the current mini-program viewport' (specific verb and resource). It distinguishes itself from siblings by focusing on screenshot capture, while other tools like mp_currentPage retrieve page info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the prerequisite of an active session and directs users to call mp_ensureConnection if none exists. This provides clear when-to-use and alternative step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
设置默认的小程序项目路径，设置后下次连接会优先使用该项目。通常用于修复项目选择失败后的后续重试。
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that setting the default affects the next connection, adding behavioral context beyond the absent annotations. However, it does not mention potential side effects, permissions, or reversibility, limiting full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and use case, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers purpose and typical usage scenario, but misses details on return values, error states, or prerequisites. It is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 0% description coverage, and the description does not mention the parameter or its intended use, providing no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'default mini-program project path', and distinguishes its purpose from sibling tools by specifying it is used for retrying after project selection failure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'usually used for retry after project selection failure.' It implies when to use but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用当前页面实例上暴露的方法。参数可以作为数组提供。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| method | Yes | ||
| args | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action (call a method) and that args can be an array, but does not disclose side effects, error behavior (e.g., unknown method), or any requirements like a valid connection. This is insufficient for zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the purpose. However, given the complexity of the tool (many schema properties), it is under-specified. Every sentence earns its place but more structure (e.g., listing important connection options) would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with a nested connection object and three parameters, yet the description provides almost no additional context beyond a one-line summary. There is no output schema, so the description should explain return values or behavior, which it does not. The description is far from complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the three parameters (connection, method, args). It only mentions that 'args can be provided as an array', which is already evident from the schema. The complex 'connection' object is completely unexplained, and the 'method' field is not elaborated. With 0% coverage, the description should compensate heavily but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'call' and the resource 'methods exposed on the current page instance'. It is not a tautology and provides a specific action. However, it does not differentiate from sibling tool 'element_callMethod', which calls methods on elements, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'element_callMethod' or when not to use it. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前页面的数据对象，可选择指定子数据路径。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'get', implying a read operation, but does not disclose any behavioral traits such as side effects, permissions, or rate limits. The description lacks explicit safety or state-change information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. It is efficient in length, but could be more structured to cover multiple aspects (e.g., parameter explanation, usage context). The conciseness is good, but sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested connection object, no annotations, no output schema), the description is severely incomplete. It does not address the critical connection parameter, nor does it provide any context about return values, prerequisites, or the overall workflow. The agent lacks essential information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The description briefly explains the 'path' parameter as a sub-data path, but completely omits explanation of the 'connection' parameter, which is a complex nested object with many subproperties. This leaves the agent uninformed about the primary parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current page's data object, with an optional sub-path. It specifically mentions 'current page', distinguishing it from sibling element-level tools like element_getData. The verb 'get' and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for page data, but does not mention when not to use it or suggest alternatives like element_getData for element-level data. The context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素，相当于 page.$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| innerSelector | No | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains returned fields and the withWxml option, but omits critical details such as the need for a connection, error handling (e.g., element not found), and whether the tool waits or returns immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a clear purpose: stating equivalency, listing returns and toggles, and noting index syntax. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It fails to cover connection requirements, return value when element is missing, or distinguish from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for selector (CSS selector, index syntax) and withWxml (returns outerWxml), but provides no information about the required connection object or the optional innerSelector parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool gets a page element by selector, equivalent to page.$(), and lists returned fields. However, it does not explicitly differentiate from the sibling tool page_getElements, which likely returns multiple elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a selector and element information is needed, but it does not provide explicit guidance on when to use this tool instead of alternatives like page_getElements or other element tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过选择器获取页面元素数组，相当于 page.$$(selector)。返回每个元素的摘要信息（tagName、text、value、size、offset）；设置 withWxml 为 true 可额外返回每个元素的完整 outerWxml。支持 [index=N] 语法选择第 N 个元素。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| withWxml | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return structure and the effect of withWxml, and mentions [index=N] syntax. However, it does not explain behavior on no matches, error handling, or the connection parameter's role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with the main action, and each sentence adds value. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description explains return fields and the withWxml option, but does not cover the connection parameter or behavior when selector matches nothing. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains selector and withWxml well, but completely omits the connection parameter, which is a complex nested object. Two out of three parameters are covered, but the missing one is significant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets an array of page elements via selector, equivalent to page.$$(), and lists returned fields. It distinguishes from sibling tools like page_getElement by specifying it returns multiple elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multiple elements via the 'equivalent to page.$$' phrase and mentions the withWxml option. However, it does not explicitly state when not to use or provide alternatives, though sibling names offer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 setData 更新当前页面的数据。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states that it updates data, with no details on side effects, permissions, or error conditions. No annotations provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too brief, missing essential context for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, output schema, or parameter descriptions, the description is severely incomplete for a tool that modifies page data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description adds no information about parameters. The required 'data' parameter remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and target (current page's data), but lacks differentiation from sibling tools like element_setData or page_getData.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like element_setData or page_getData, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
等待指定选择器的元素出现在页面上。支持 [index=N] 语法选择第 N 个元素。增强版：增加了超时和重试间隔参数。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| selector | Yes | ||
| timeout | No | ||
| retryInterval | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions timeout and retry interval, but does not specify behavior on failure (e.g., timeout error), return value, or side effects. The description is insufficient for an agent to fully predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences. It front-loads the primary purpose and then adds secondary features. No redundant information. However, it could be slightly more structured by separating core purpose from enhancements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex 'connection' parameter, no output schema, and no annotations, the description is incomplete. It omits explanation of the connection object, error handling, and return values. The description only covers selector semantics and basic retry/timeout, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the selector parameter by explaining the [index=N] syntax. It also states timeout and retry interval are 'enhanced' parameters. However, the complex 'connection' object is left unexplained, and other parameters lack context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for an element specified by a selector to appear on the page. It mentions support for [index=N] syntax, which adds clarity about selecting specific elements. However, it does not explicitly distinguish this tool from siblings like page_waitTimeout or page_getElement, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, common use cases, or when not to use it. The sibling tools suggest broader workflow, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
等待指定的毫秒数。
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No | ||
| milliseconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action of waiting and does not cover whether the wait is blocking, cancellable, or how it interacts with page lifecycle. No additional traits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It does not front-load key information or use formatting to aid readability. While efficient, it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple parameters (including a nested connection object) and no annotations or output schema, the description is severely incomplete. It omits return behavior, error conditions, and prerequisites, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for either parameter. The 'milliseconds' parameter is somewhat self-explanatory from its name, but the complex 'connection' object is completely undocumented. The description fails to provide any semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a specified number of milliseconds. The name 'page_waitTimeout' implies time-based waiting, and the description confirms the unit. However, it does not differentiate from sibling tools like page_waitElement, which wait for a condition rather than a fixed duration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios where a fixed delay is preferable to conditional waits, nor does it provide context on prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.4element_callMethodelement_getAttributeselement_getBoundingClientRectelement_getDataelement_getInnerElementelement_getInnerElementselement_getStyleselement_getWxmlelement_inputelement_scrollToelement_setDataelement_tapmp_callWxmp_currentPagemp_ensureConnectionmp_getLogsmp_listProjectsmp_navigatemp_screenshotmp_setDefaultProjectpage_callMethodpage_getDatapage_getElementpage_getElementspage_setDatapage_waitElementpage_waitTimeoutv0.1.6element_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutv1.0.0element_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getInnerElements2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getSize2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_getWxml2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_input2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_tap2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_callWx2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_ensureConnection2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_getLogs2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_navigate2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsemp_screenshot2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_callMethod2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_getElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_setData2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitElement2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsepage_waitTimeout2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseelement_callMethodelement_getDataelement_getInnerElementelement_getInnerElementselement_getSizeelement_getWxmlelement_inputelement_setDataelement_tapmp_callWxmp_ensureConnectionmp_getLogsmp_navigatemp_screenshotpage_callMethodpage_getDatapage_getElementpage_setDatapage_waitElementpage_waitTimeoutScored across 27 tools
Each tool targets a distinct action within its category (element, mp, page). Within each group, operations like getAttributes, getBoundingClientRect, getData are clearly different. No two tools overlap in purpose.
All tools follow a consistent pattern: category_verbNoun (e.g., element_tap, mp_navigate, page_setData). Underscore separation and camelCase for the verb+noun are uniform across all 27 tools.
With 27 tools, the count is on the higher side but well-justified by the broad scope (element manipulation, page control, and mini-program API calls). It's reasonably scoped for a comprehensive development assistant.
The tool set covers core operations: element querying/interaction, page data management, and mini-program API invocation. Minor gaps like gesture simulation or file operations exist, but the essential CRUD and lifecycle actions are present.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Give your AI agents the tools to build, manage, and run automation workflows.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
