Wechat Devtools MCP
Server Quality Checklist
Latest release: v0.0.2
- Disambiguation4/5
Each tool has a distinct purpose, but some overlap exists between element_value, element_property, and element_attribute, as well as between page_query and element_query, which could cause misselection without careful reading. Overall, descriptions clarify the differences.
Naming Consistency4/5Tool names are mostly consistent with a verb_noun pattern and snake_case, using page_ and element_ prefixes. Minor deviations like 'status', 'screenshot', and 'evaluate' break the pattern slightly but are still readable.
Tool Count1/5With 61 tools, this server is far too large for an MCP server. Many tools could be consolidated with parameters (e.g., query selector type), and the sheer number makes it difficult for agents to choose appropriately.
Completeness5/5The tool set covers the full lifecycle: connection, navigation, page inspection, element interaction, logging, mocking, and evaluation. There appear to be no major gaps for the stated purpose of controlling WeChat DevTools.
Average 3.4/5 across 61 of 61 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without detailing what happens after the long press (e.g., duration, side effects, return value, required permissions). This is a significant gap for a gesture-based tool that likely triggers platform-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a single phrase that restates the tool name, failing to provide any detail that would help an agent invoke the tool correctly. There is no structure or additional context to aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema) the description is minimally adequate, but it leaves critical questions unanswered: what happens after long press, whether the element must be scrolled into view, and what the return value or side effects are. For a tool interacting with a mobile application UI, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (element_id, string) with zero description coverage. The description implies that element_id is the target element, but it does not explain how to obtain or reference the element, nor does it clarify the expected format or scope. The description adds minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '长按元素' ('long press element') is essentially a direct translation of the tool name 'element_longpress' and adds no new information. It states the action and resource but does not distinguish this tool from siblings like element_tap or element_touch, nor does it clarify the effect of a long press.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative gestures (tap, swipe, touch) or any mention of prerequisites such as element visibility or prior element querying. The description provides no context about typical use cases or scenarios where a long press is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that the tool retrieves page size, but provides no details about return format, units, error behavior, or any side effects. For a tool with no metadata, this 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and efficient, though extremely brief. It earns its place by stating the core function, but lacks supporting detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 incomplete. It does not explain what the return value represents, what units are used, or how errors are handled. The tool's sole parameter is also undocumented, leaving significant gaps for an agent attempting to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no additional meaning for the 'page_id' parameter. The description does not mention 'page_id' at all, leaving the agent without any explanation of what this parameter represents or how it should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取页面尺寸（宽高）' which means 'Get page size (width and height)'. It specifies a concrete verb and resource, making the tool's function clear. However, it does not explicitly differentiate from sibling tools like element_size, though the 'page' vs 'element' distinction is implicit in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or scenarios where this tool should be preferred over other page-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic move action and does not disclose potential side effects, coordinate semantics (absolute vs offset), animation behavior, or required component properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and easy to parse. It front-loads the core purpose perfectly, though it could be slightly more detailed without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, an output schema, and minimal parameter documentation, the description is incomplete. It does not explain return values, error conditions, prerequisites for using this tool, or how it differs from similar operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only y has a description). The tool description adds no parameter meaning beyond 'specified position', and does not explain what x and y represent or how they relate to the movable-view's coordinate system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '移动 movable-view 到指定位置' clearly states the action (move) and the resource (movable-view to a specified position). It is specific enough to distinguish from sibling tools like element_scroll_to or element_swipe_to, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or context such as requiring a movable-view component or how coordinates should be interpreted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states 'click element' without mentioning potential side effects, authorization needs, or whether it requires the element to be in the current page. For a mutation action, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no wasted words, but it is under-specified. It lacks structure and any additional context that would help the agent, making it borderline between effective conciseness and insufficient detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description may be minimally sufficient, but given the abundance of sibling element tools, it does not clarify how element_tap differs from element_touch or element_trigger. It also omits details like required connection state or element visibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 element_id parameter. While the parameter name is self-explanatory, the tool description offers no additional context, such as how to obtain the ID or any constraints on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '点击元素' (click element) clearly states the action (click) and the resource (element). It is a specific verb-resource pair and is easy to understand. However, it does not differentiate from sibling tools like element_touch or element_trigger, which could be similar actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, such as whether the element must be visible or whether a connection is required, nor does it suggest when to prefer this over element_longpress or element_trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It only describes the action and fails to mention side effects, prerequisites, return values, or whether the swipe is simulated or triggers events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is concise and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling element tools and the absence of annotations or output schema, the description is too terse to fully support correct invocation. It lacks usage conditions, parameter details, and behavioral context needed for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explicit parameter guidance. The 'index' parameter is already described in the schema ('目标滑块 index'), and 'element_id' remains unexplained; the description only implies the element is a swiper.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '滑动 swiper 到指定滑块' clearly identifies a swipe action on a swiper component to a target slide. It uses a specific verb and resource, but does not explicitly distinguish itself from similar sibling tools like element_slide_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only states the action, leaving the agent without criteria to choose between element_swipe_to and other element interaction tools such as element_slide_to or element_scroll_to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states that it calls a method, but does not disclose whether the call has side effects, what the return value looks like, whether arguments are passed positionally, error behavior, or any permissions/authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core purpose. There is no redundant or filler content, and the most important keywords are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool invokes arbitrary component methods, the description is too sparse. It lacks essential context such as return values, argument-passing conventions, restrictions on which component types support methods, and potential side effects. The presence of many similar sibling tools also increases the need for clearer differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, above the 50% threshold but not high. The schema itself describes the method parameter as '仅自定义组件可用', adding a useful constraint. However, element_id has no description, and args is only described as '方法参数' without explaining ordering or structure. The tool description does not add substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: calling a custom component instance method. It specifies the resource type ('自定义组件实例方法'), which helps distinguish it from generic page-level method calls, though it does not explicitly contrast with the similar sibling tool element_call_context_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions '仅自定义组件可用' as a precondition, but it does not explain when element_call_method is preferred over element_call_context_method, page_call_method, or other call-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the basic operation. It does not mention side effects (e.g., triggering change events), validation (e.g., value range), or behavior when the element is not a slider. With no annotations to provide context, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose without superfluous words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description still falls short. It does not explain when to use it (e.g., after identifying a slider), potential error conditions, or the effect of setting a value. The lack of annotations and output schema makes the description insufficient for confident usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with only 'value' described. The description adds the 'slider' context but does not explain 'element_id' (e.g., what identifier to use) or clarify the expected format or constraints for the value, leaving the undocumented parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置 slider 组件的值' clearly states the action (set value) and the resource (slider component). It distinguishes itself from siblings like element_input (text input) and element_swipe_to (gesture operation) by specifying the slider context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, such as requiring a slider element, or explicitly contrast with similar operations like element_input or element_set_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing side effects. It only states the basic scroll action without mentioning whether scrolling is animated, whether it applies to the main page or a scrollable container, or how out-of-range positions are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description is too minimal to be standalone. It does not explain return values, side effects, or edge cases, and with no annotations it leaves the agent without important behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter scrollTop is already fully documented in the schema with its meaning and unit (px). The description adds no additional semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '将当前页面滚动到指定位置' clearly identifies the action (scroll), the resource (current page), and the target (specified position). It distinguishes from the sibling page_scroll_top by allowing arbitrary positions, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like page_scroll_top or element_scroll_to. The description is purely actional and lacks any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the condition semantics but omits important runtime behaviors such as timeout throwing, polling behavior, or side effects. The timeout parameter description in the schema mentions timeout errors, but the tool description itself does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, highly efficient and front-loaded. It captures the core behavior in a compact form without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is too minimal. It fails to mention timeout behavior, error conditions, or when to use it, leaving the agent with significant gaps in understanding how to invoke and rely on the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for timeout and condition, and the tool description essentially repeats the condition semantics without adding new information. With 67% schema coverage, the description adds minimal value and does not clarify the page_id parameter, though its purpose is fairly obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a condition and specifies two condition types (number = milliseconds, string = element selector). It is unambiguous and uses a specific verb (wait) with a resource (condition). It does not explicitly distinguish from sibling tools, but no other wait tool exists, so this is acceptable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what the tool does without mentioning typical use cases, prerequisites, or when other page/element tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic action of setting the ticket, but does not mention side effects, validation, persistence, or whether it overwrites existing tickets. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose directly. It is front-loaded and contains no filler. However, it is arguably too terse, lacking useful context, but conciseness itself is well-achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (1 parameter, no output schema), the description is minimal and does not explain the role of the ticket in the broader developer tool context. It lacks any relationship to get_ticket/refresh_ticket, and provides no information about expected outcomes or edge cases. For a tool with siblings, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the parameter 'ticket' has a description ('登录票据'). The tool description essentially repeats that same phrase and adds no additional meaning, such as format, constraints, or examples. Baseline 3 is appropriate when the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置开发者工具登录票据' clearly states the action (set) and the resource (developer tool login ticket). It is specific and unambiguous, but does not explicitly distinguish from sibling tools like get_ticket or refresh_ticket, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, contexts, or relationships to get_ticket/refresh_ticket. The usage context is entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning side effects, requirements (e.g., element visibility), event propagation, or return behavior. This is a significant gap for a tool that triggers events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. No wasted words, and structure is appropriate for a tool with such a simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of many sibling tools, the description is too sparse. It does not provide enough context about behavior, when to use versus alternatives, or how the 'detail' parameter works. The tool remains ambiguous for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema; it repeats the type description but does not clarify element_id (which has no schema description). With 67% schema coverage, the description should compensate for missing parameter details but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '触发元素事件（如 change / blur)' clearly states the tool triggers element events with examples, distinguishing it from sibling tools like element_tap and element_input. It is specific but could be slightly more explicit about the target element (element_id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool when needing to fire DOM events like change or blur. However, there is no explicit guidance on when not to use it or which alternatives to prefer, so it only partially addresses this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It discloses that the tool returns rendering data, optionally filtered by a path, and that omitting the path returns everything. However, it does not mention return format, potential errors, or side effects. This is a basic transparency level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a parenthetical clarification. It front-loads the main purpose and adds the key optional behavior without wasted words. However, it is under-specified for some dimensions, which is a completeness issue rather than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description provides enough to understand the core function. But it lacks details on return structure, error cases, or when to use it among many sibling tools. With no annotations, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (path is described, page_id is not). The description repeats the path behavior but adds no new information beyond the schema. It fails to explain page_id, which remains unclear. Thus, the description does not compensate adequately for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取页面渲染数据' (get page rendering data). While it doesn't explicitly differentiate from siblings like page_query or page_query_all, the term '渲染数据' (rendering data) gives a distinct resource. The optional path specification adds useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions. The parenthetical '可指定路径，不传返回全部' (can specify path, returns all if not passed) is a usage hint for the path parameter but does not explain context or timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without describing side effects, prerequisites, return values, or any constraints. The description does not go beyond the bare purpose, leaving the agent uninformed about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is front-loaded and easy to parse, though it sacrifices informative depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with no annotations, no output schema, and only partial parameter coverage. It lacks information about return values, behavioral outcomes, and prerequisites. While the tool is simple, the description does not provide enough context for an agent to fully anticipate the invocation result or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions, but the tool description adds no parameter semantics. It does not explain any parameter or relationship between parameters. Even the element_id parameter, which is required, lacks any description in both the schema and the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('调用' = call) and the resource ('video 组件上下文 Context 方法' = video component context method). This distinguishes it from the sibling element_call_method, which targets general element methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, exclusions, or preferred scenarios. The only hint about the requirement of a video component with an id appears in the schema, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It is a getter, which implies a read-only operation, but the description does not mention any side-effects, return format, or error behavior. It merely restates the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose with an example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description provides the essential idea, but it lacks differentiation from closely related sibling tools and doesn't clarify expected return behavior. It is minimally viable but leaves contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (name described, element_id not). The description adds a clarifying example for the 'name' parameter ('如 input 组件的 value'), but element_id remains underspecified. This partially compensates for the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取元素属性值' (get element attribute value) with a concrete example. However, it does not differentiate from sibling tools like element_attribute or element_value, which likely overlap significantly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_attribute or element_value. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for transparency. It only states the action and does not disclose read-only behavior, return format, error handling, or side effects. The word 'get' subtly implies a read operation, but this is minimal and not sufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no filler or irrelevant information. It is front-loaded and appropriately brief given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is minimal. It fails to describe the return value (the text content itself) or any edge cases, and with no output schema to fill gaps, an agent lacks crucial context for handling the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (element_id) with 0% description coverage. The description does not mention element_id, how to obtain it, or its expected format, providing no added value beyond the schema's raw type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取元素文本内容' (Get element text content) uses a specific verb and resource, clearly distinguishing it from sibling tools like element_attribute or element_value. It is unambiguous about what 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies usage for reading an element's text content, but it does not mention exclusions or alternative tools, making it merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'trigger' touch events, without revealing whether these are synthetic dispatches, whether they wait for handlers, or any side effects. No additional behavioral context is given, limiting the agent's understanding of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and event types. Every word earns its place, with no redundancy or vague language. It is appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and many siblings, the description is too sparse. It fails to explain the role of touches/changedTouches, how to structure the event data, or what happens after triggering. The agent lacks sufficient context to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 75% (3 of 4 parameters have descriptions), but the tool description itself adds no meaning to any parameter. The required element_id lacks a description and the description does not compensate. The agent must infer semantics from the schema alone, which is insufficient for the events' details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: triggering element touch events, listing the specific event types (touchstart/touchmove/touchend) and the resource (element). This distinguishes it from sibling tools like element_tap or element_longpress by focusing on raw touch events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or context where a different event simulation (tap, longpress, trigger) would be more appropriate. The agent is left without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool navigates to a non-tabBar page, but does not disclose whether the current page stays in the stack, whether query parameters are supported, or any side effects on the page navigation history. This is minimal and insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the key action and target. It is compact and to the point, though it is so terse that it leaves out important behavioral details, but that is a completeness concern rather than a conciseness defect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), but the description does not address critical context such as page stack behavior (push vs redirect), whether the url can include query parameters, or success/failure semantics. Given the presence of sibling tools like redirect_to and switch_tab, this omission leaves an agent under-informed for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single url parameter fully (100% coverage) with a type, description, and example. The tool description adds no additional meaning beyond the schema, which is acceptable because the schema already explains the parameter adequately. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb '跳转到' (navigate to) and specifies the resource as '应用内非 tabBar 页面' (in-app non-tabBar page), distinguishing it from tools like switch_tab which target tabBar pages. However, it does not explicitly say whether this pushes a new page onto the stack (navigateTo semantics) or replaces the current page, which makes it slightly ambiguous versus redirect_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is for non-tabBar pages, which gives one clear context signal and implicitly contrasts with tabBar navigation tools. It does not, however, explicitly mention when not to use it or name alternatives like redirect_to or switch_tab, so an agent must infer the decision from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing side effects, prerequisites, return values, or error behavior. It only describes the action (calling a method) without any warning about potential side effects or what happens after invocation, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that clearly states the tool's function and includes helpful examples. It is front-loaded with the main verb and resource, with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a moderately complex action (method invocation), the description is too sparse. It does not mention return values, error handling, or whether the call may trigger side effects, leaving the agent with insufficient context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information. The schema already covers 'method' and 'args' with descriptions, but 'page_id' is undocumented in both schema and description. Since schema coverage is only 67% and the tool description provides no further clarification, the description fails to compensate for the missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '调用页面实例方法' (invoke page instance methods). It provides concrete examples (onPullDownRefresh, custom methods) and distinguishes this tool from siblings like element_call_method or call_wx_method by explicitly focusing on page instance methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by indicating it covers event methods and custom methods, but it does not explicitly state when to use this tool over alternatives (e.g., element_call_method) or provide any exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the return type (element_id handle) but does not describe what happens when no element matches, whether the operation is read-only, or any error conditions. This is insufficient for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and return value. Every word contributes to understanding the tool's purpose without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sparse schema (no output schema, no annotations), the description is too minimal. It does not explain how to obtain page_id, what to do with the returned element_id, or how this tool fits into the larger workflow. The lack of usage context makes it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (only selector has a description), and the tool description does not explain page_id at all. The description repeats the selector type already in the schema, adding no new meaning for the parameters. It fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the first matching element in a page using a WXSS selector and returns an element_id handle. It uses specific verbs and resources, and the mention of 'first' distinguishes it from page_query_all and other query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like page_query_all or page_query_xpath. The phrase 'first matching element' implies a single-result use case, but no explicit exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool calls a method and returns the result, but omits details about error handling, asynchronous behavior, or side effects. The description adds no context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's function. There is no unnecessary repetition or filler, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters, the overall description lacks essential context for a tool with no annotations and no output schema. Behaviors like error responses, synchronous vs. asynchronous execution, and restrictions on callable methods are not mentioned, making the description incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'method' and 'args' having meaningful descriptions. The tool description itself does not mention parameters, but the schema already provides adequate semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: calling a wx global method within the AppService and returning the result. It distinguishes itself from sibling tools like call_page_method (page methods) and mock_wx_method (mocking), making the action and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mock_wx_method or page_call_method. The description does not mention any exclusions or conditions, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the action (get attribute value) without disclosing return behavior, error conditions, permissions, or side effects. This is minimal even for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose with examples. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description captures the core function but omits usage guidance and fails to explain element_id. With no output schema, it only partially implies what the tool returns (the value). Overall, adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the 'name' parameter with examples (class/id/src), and the tool description repeats these examples. However, the 'element_id' parameter has no description in either the schema or the description, leaving its meaning ambiguous. With 50% schema coverage, the description does not compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取元素特性值（如 class / id / src）' clearly states the tool retrieves attribute values for elements, with specific examples. It distinguishes from sibling tools like element_property, element_text, and element_value by specifying attributes (class/id/src) rather than properties, text, or values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention sibling tools or any exclusions. Usage is only implied by the clear purpose, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It only states the query scope and match criteria, but omits critical behavior such as what happens when no match is found, whether it performs a read-only operation, or the return format. This is insufficient for a resource query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the action verb '查询' and includes all key scoping information (within element, WXSS selector, first match). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple tool has only 2 parameters and no output schema, but the description still feels incomplete. It fails to state what the query returns (e.g., the element ID of the matched child) or any error behavior. Given the tool's simplicity, a more complete description is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'selector' parameter with a description, but 'element_id' lacks any description. The tool description adds context by indicating '在元素内' (within element), subtly explaining that element_id identifies the parent element and clarifying the relationship between parameters. However, it does not fully compensate for the missing element_id schema description, so it is adequate but not excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '查询首个匹配子元素' (query the first matching child element) using a WXSS selector, with an explicit scope '在元素内' (within an element). It distinguishes from the sibling 'element_query_all' by specifying '首个' (first match).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or comparison with alternatives is provided. It implies usage for querying a single child element, but does not explicitly contrast with element_query_all or page_query tools, leaving selection criteria ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic getter action without revealing return type, potential errors, or whether the element must render first. Minimal behavioral context beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the essential purpose without unnecessary words. It is perfectly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description should explain return values and any caveats. It only states the action and property, leaving the agent uncertain about what the result looks like or when the tool might fail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (element_id) with no description, and the schema description coverage is 0%. The description does not mention or explain the parameter, so it adds no semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' = get) and the resource ('元素可滚动高度' = element's scrollable height), and explicitly mentions the property name scrollHeight. This distinguishes it from sibling tools like element_scroll_width and element_scroll_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the purpose—use when you need the scroll height of an element. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must disclose behavior. It only indicates a read operation ('get') but does not mention return format, behavior on missing styles, or whether it returns computed or inline styles. This is a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately sized for the simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple 2-parameter schema, but with no output schema or annotations, the description could benefit from noting the return type or edge cases. It covers the core purpose but omits behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'name' parameter with examples, and the description repeats those examples. The 'element_id' parameter is left undefined in both schema and description, though its purpose is inferable from the tool name. Overall, the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves element style values, with examples ('color', 'fontSize'). This distinguishes it from sibling tools like element_attribute (attributes) and element_property (properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as element_attribute or element_property. The description only states what it does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions that the tool gets a value from form components, but it does not describe return format, error behavior, or what happens for non-form elements. This is a minimal addit Ion beyond the name, leaving significant behavioral details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('获取元素值') and provides a clarifying parenthetical about applicable element types. Every word earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify return values or edge cases, but it does not. The tool is simple (one parameter), but the description lacks details about what the returned value represents or how to handle non-form elements, making it incomplete for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, element_id. The description does not explain the parameter or its expected format, leaving the agent to infer from the name alone. Since the description adds no meaning beyond the schema, it does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取元素值' (get element value) and specifies the resource type ('input/textarea 等表单组件'), which distinguishes it from sibling tools like element_text or element_attribute. It uses a specific verb and resource, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for form components (input/textarea), giving context about when to use the tool. However, it does not explicitly mention alternative tools or state when not to use it, so the guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It adds useful context: timeouts, auto-detection of CLI path and project path, and the trustProject behavior to avoid blocking. However, it doesn't disclose what happens on success/failure, whether the process is blocking, or any side effects, leaving significant gaps for a launch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the primary action. It includes the essential purpose without excessive detail. The phrase '等参数' (etc.) adds slight vagueness but does not significantly detract. Overall, it is appropriately sized for a tool with a well-described schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters), the absence of annotations, and no output schema, the description is insufficiently complete. It does not explain the return behavior, prerequisites, or how this launch step fits into the broader tool ecosystem (e.g., that it likely must succeed before other tools like 'connect' or element queries are used). This is a critical gap for an initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description merely lists parameter types ('支持项目路径、cli 路径、端口、票据等参数') without adding semantic meaning beyond the schema. It doesn't explain relationships, defaults, or the significance of the parameters, but the schema already documents each parameter thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's main action: '启动微信开发者工具并连接小程序' (launch WeChat developer tools and connect to mini program). It also lists key parameters (project path, CLI path, port, ticket), making the resource and scope clear. However, it does not explicitly differentiate from sibling tools like 'connect' (which might attach to an already running instance), though the verb 'launch' implicitly distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (start the dev tools and connect) but provides no explicit guidance on when to use this tool vs alternatives. It does mention auto-detection defaults and the recommendation to set trustProject=true, which are usage hints but not alternatives. No exclusions or when-not conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action. It does not mention whether existing text is replaced or appended, whether the element needs focus, or any side effects. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extra words. It achieves maximum conciseness while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the basic purpose and the target element type. However, with no annotations and no behavioral details, it remains incomplete as a standalone reference. It would benefit from clarifying how the input is applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: value has a description, but element_id does not. The description adds no parameter-specific meaning, leaving element_id completely undocumented. The phrase '输入文本' only vaguely aligns with the value parameter and does not help clarify how parameters work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '向 input/textarea 组件输入文本' (input text into input/textarea component) clearly states a specific verb+resource. It differentiates from siblings like element_tap (tap action) and element_value (retrieve value), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for input/textarea components, but the description does not explicitly state when to use it versus alternatives, nor any exclusions. It lacks guidance such as 'use this instead of element_call_method for text entry' or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述承担全部责任。提供了相对视口这一关键行为，但未说明返回值格式、错误情形或是否适用于隐藏元素，信息量有限。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
一句话简洁明了，无冗余，信息充分。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单（1个参数），描述基本说明了用途和关键限定，但缺乏参数解释和使用场景，考虑整体简单性尚可但有明显空缺。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema未描述element_id，工具描述也未提及该参数。仅参数名暗示其含义，描述未提供额外语义，而schema覆盖率低，描述应做补偿但未做。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具是获取元素位置偏移（相对视口），动词和资源清晰，能与其他元素查询工具（如element_size、element_text）区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未提供何时使用此工具、何时不使用或替代方案的信息，在众多元素工具中缺乏选择指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb '获取' implies a read operation, but no explicit statement about side effects, return format, or error behavior is given, though for a getter this is somewhat implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It efficiently states the tool's purpose and the relevant DOM property.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimally adequate: it states the action and target. However, it omits the return type (e.g., numeric pixel value) and any behavior on invalid element_id, which are natural gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, element_id, has no schema description and the tool description does not explain how to identify the element beyond the word 'element'. The description adds minimal value over the schema's property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取元素可滚动宽度（scrollWidth）' uses a specific verb ('get') and resource ('element scrollable width'), and explicitly names the property (scrollWidth), clearly distinguishing it from siblings like element_scroll_height.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_scroll_height or element_scroll_to. The description only states what the tool does, leaving the agent to infer use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read-only query operation, but does not disclose the return format, possible error cases, or whether additional information is included. The description is accurate but lacks depth expected for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's function. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params), but there is no output schema and the description does not explain the structure of the returned status or page stack data. Given the potential for ambiguity about what 'status' means, the description is somewhat incomplete but adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to clarify. The baseline of 4 applies because the description need not compensate for any parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying current connection status and page stack information. It uses a specific verb '查询' (query) and identifies two distinct resources, distinguishing it from siblings like 'page_stack' which only covers page stack, though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives like 'page_stack' or 'system_info'. The description only states what it does, without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states that logs are cleared but fails to mention irreversibility, scope of effect (e.g., session-global), or any side effects. For a destructive action, this is insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly and completely states the tool's function. There is no redundancy or missing clarity for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter tool, the description covers the basic action but omits critical context such as the destructive nature, relationship to log-collection sibling tools, and any prerequisites or consequences. Without annotations, the description should provide more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. As per the baseline for 0-parameter tools, the description need not add parameter details. It correctly focuses on the action itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '清空' (clear) and identifies the resource '已收集的控制台日志与异常记录' (collected console logs and exception records), making the function unambiguous. It clearly distinguishes from sibling tools like console_messages and exception_messages which collect logs, while this one clears them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention using it after reading logs, nor does it note that it is meant to reset log state. The usage context is only implied by the tool name and sibling relationships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 primary behavior (disconnect and close the project window), but does not mention side effects such as whether unsaved changes are lost or if a confirmation is required. For a state-changing tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is mostly complete. It could be improved by explaining how 'close' differs from the sibling 'disconnect' tool, but the core function is clearly conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is vacuously 100%. With no params to document, the description does not need to add parameter detail, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('disconnect and close') and the resource ('project window in developer tools'). It distinguishes from the sibling 'disconnect' by adding the closing of the project window, though this differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'disconnect'. The description only states what it does, without any context or exclusion conditions. An agent would not know if 'close' is preferred over 'disconnect' in certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'get' and specifies that width and height are returned, but it does not disclose units, return format, or behavior for invalid elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese with no extraneous words. It is front-loaded and every character contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description only states the core function. It lacks details such as return structure, units, and edge cases, but for a simple read tool with a single parameter, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, element_id, with 0% schema description coverage. The description does not explicitly explain element_id, but the parameter name is self-explanatory, and the tool's purpose implies an element must be identified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取元素尺寸（宽高）' clearly states the tool's function: get the element's size (width and height). The verb 'get' and resource 'element size' are specific and distinguish it from sibling tools like element_text or element_offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is only a short phrase that states the action. It does not disclose behavior such as error handling when no previous page exists, synchronization semantics, or side effects, which is a gap for a navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that efficiently conveys the tool's purpose. It is appropriately sized for a zero-parameter navigation tool, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of an output schema, the description captures the core purpose. However, it omits potential edge-case behavior (e.g., navigating back from the root page), which reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description and schema fully cover the parameter situation (empty), and no additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description '返回上一页面' clearly states the action of navigating back to the previous page, using a specific verb and resource. It differentiates itself from sibling tools like navigate_to or redirect_to by focusing on backward navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as page_stack or current_page. It does not mention prerequisites, exclusions, or conditions like whether a previous page exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 states the action (get scroll position) but does not disclose return format, whether it returns only scrollTop or also scrollLeft, or any error conditions. For a simple read operation this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the core purpose. There is no redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimal. It does not explain the meaning of page_id, the return value, or any prerequisites. While the name clarifies the return, the description alone leaves significant gaps for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one parameter page_id with only a type and no description. The tool description does not mention page_id or its meaning at all. With 0% schema description coverage, the description fails to compensate, leaving the agent to infer page_id is the target page identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取页面滚动位置（scrollTop）' clearly states a specific verb+resource: getting the page's scrollTop value. It distinguishes itself from sibling tools like page_scroll_to (which sets scroll position) and element_scroll_to (which targets elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives, but the purpose implies using it to read the page's current scroll position. There is no mention of exclusions or alternative tools, so it relies on the name and sibling context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It surfaces key constraints: only custom components are supported, and an optional path can be specified. However, it does not disclose return format, error behavior for non-custom elements, or whether this is strictly a read operation, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. The key action and constraint are front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description is minimally adequate. It covers the core purpose and primary constraint but omits return-value format and potential error cases. Given the tool's narrow scope, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only 'path' is described. The description adds no new meaning beyond the schema, and 'element_id' remains unexplained in both schema and description. Since coverage is below 50%, the description should compensate, but it fails to clarify the role of element_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: '获取自定义组件 data' (get custom component data). It clearly identifies the target and adds the scope constraint '仅自定义组件可用' (only custom components), which distinguishes it from sibling getters like element_text or element_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving custom component data but does not explicitly compare with alternatives or state when not to use it. The '仅自定义组件可用' constraint provides some guidance, but no explicit exclusions or alternative tool references are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It mentions the default port but omits key details such as the WebSocket nature, prerequisites (DevTools running, automation enabled), the effect of a failed connection, or whether this is required before other automation tools. The schema hints at WebSocket, but the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('连接到...小程序') and immediately states the default endpoint behavior. There is no filler or redundancy, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without annotations or an output schema, the description explains the purpose and the default parameter. However, it does not describe return values, error conditions, or any necessary prerequisite to use this tool before others. It is minimally sufficient but leaves some gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents wsEndpoint with full coverage, including its default behavior ('缺省时使用 --port 指定的端口'). The tool description echoes this default but adds no new meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to a mini program already running in WeChat DevTools, providing a specific verb and resource. It distinguishes this from siblings like 'launch' (which starts a new instance) by explicitly noting '已在运行中' (already running).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '已在微信开发者工具中运行中' implicitly tells the user this should be used after a program is running, not to start one. It also explains the default local connection, but it does not explicitly contrast with 'launch' or 'disconnect' or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only provides the basic action without disclosing side effects, prerequisites, or error behavior. It does not mention coordinate handling, smoothness, or what happens if the element is not a scroll-view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations or output schema, the description lacks details on return values, errors, and prerequisites. It does provide the key context of targeting scroll-view, but leaves out additional behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 33% description coverage (only y has a description). The description adds that the tool scrolls to a specified position, implying x and y are coordinates, but does not elaborate on element_id or coordinate system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '滚动 scroll-view 到指定位置' (scroll scroll-view to specified position), specifying the verb 'scroll', the resource 'scroll-view', and the action's target. This distinguishes it from sibling tools like page_scroll_to and element_swipe_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies scroll-view as the target, giving clear context for when to use the tool. However, it does not explicitly state when not to use it or name alternative tools, making it less explicit than the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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. It only states that it modifies data and is restricted to custom components; it does not disclose whether the data object is merged or replaced, whether side effects occur, or error behavior. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the action and the main constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required params and no output schema or annotations. The description covers the core purpose and restriction but omits behavioral details such as merge semantics, response, and prerequisites like how to get element_id. It is adequate for a simple setter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the 'data' parameter has a description, but 'element_id' does not. The tool description adds the context that the data belongs to a custom component, which helps infer element_id's purpose, but does not explain how to obtain it or the expected format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '修改' (modify) and resource '自定义组件 data' (custom component data), and explicitly states the constraint '仅自定义组件可用' (only custom components). This clearly differentiates it from sibling tools like element_data (getter) and page_set_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for modifying data on custom components only. It states an exclusion ('仅自定义组件可用') but does not explicitly name alternatives for non-custom elements. This is sufficient guidance for selection in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 core behavior of injecting and executing code and returning results, and adds context about global access. However, it does not mention error handling, potential side effects, synchronous/asynchronous execution, or security implications, which are important for a code execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action (inject and execute code) and includes relevant context (global access). There is no filler or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a code execution tool with no output schema and no annotations. The schema covers parameters well, but the description does not cover important behavioral aspects such as return value format, error handling, or how the function's return value is serialized. For a powerful code injection tool, the context is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'args' and 'code'. The tool description adds a note about global access, but the schema's code example already demonstrates getApp().globalData.userInfo, so the description offers only marginal additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool injects function source code into AppService, executes it, and returns the result. It also mentions access to globals like getApp/getCurrentPages, which distinguishes it from sibling tools like call_wx_method or page_call_method that target specific APIs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for executing code with global access in the AppService context, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. No guidance is given on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the return is an element_id handle, which is useful, but it doesn't state behavior when no element matches, whether it waits, or if any errors occur. The query nature implies read-only, but this isn't explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core action, no filler. The description efficiently conveys purpose and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter query tool without output schema or annotations, the description covers the primary purpose and return type. However, it omits edge-case behavior (e.g., no match, invalid XPath) and assumes the agent knows how the returned handle should be used. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only xpath is described with an example). The description adds meaning by explaining the XPath query concept, but it doesn't elaborate on page_id beyond the context of '在页面中' (in the page). Page_id remains under-documented, and the description doesn't fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the first matching element by XPath and returns an element_id handle. It distinguishes from siblings like page_query_all and page_query_xpath_all by specifying '首个匹配元素' (first matching element). Verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the first XPath match on a page, but it doesn't explicitly mention alternatives or exclusions. No guidance on when to prefer this over page_query_xpath_all or page_query, leaving the agent to infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It discloses the critical behavior that the tool directly changes data without triggering reactive updates, which is a significant side effect. However, it does not mention whether data is merged or replaced, whether the change is persistent across reloads, or any error conditions. This leaves notable gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action ('修改页面渲染数据') and follows with two important behavioral details. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is succinct and captures the core intent, but misses several contextual aspects: whether the data is replaced or merged, what the tool returns (though no output schema exists), and any prerequisites like the page being loaded. Given the tool's complexity (2 params, nested object) and lack of annotations, the description could provide more context to be fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters: 'data' has a description ('要改变的数据对象'), while 'page_id' has no description. The tool description adds minimal parameter context—it reinforces that data is modified but does not explain the expected structure or clarify page_id. Since coverage is at the 50% threshold and the description adds little beyond the schema, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '修改页面渲染数据' clearly names the verb (modify) and resource (page rendering data), and the added qualifier '直接改 data，不触发组件响应式更新' distinguishes it from sibling tools that might trigger updates or operate on elements. This makes the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '适合调试' provides a clear context (debugging) suggesting when to use this tool. However, it does not explicitly state when not to use it or name alternative tools (e.g., element_set_data or page_call_method) for reactive updates. Thus usage guidance is present but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does reveal a side effect: registering a page_id handle. However, it does not explain the purpose of the handle, whether it requires cleanup (e.g., via release_handles), or any other behavioral traits like ordering or inclusion of the current page. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. The parenthetical clarifies the scope and side effect without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should clearly explain return value and any side effects. It does state that it returns the page stack and registers a handle, but it leaves important gaps: what is the handle used for, does it need releasing, and what is the return structure (array of objects, ids, etc.)? It is adequate for a simple getter but misses key contextual details about the handle lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds no parameter-specific details, but none are needed since the schema is empty and coverage is 100%. The description's mention of what the tool returns (page stack and handle) provides context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (获取/get) and resource (页面栈/page stack), and explicitly states it retrieves all open pages while registering a page_id handle. This distinguishes it from siblings like current_page (which likely retrieves just the current page) and page_size (which likely returns the stack size).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as current_page or page_query. It does not mention any prerequisites, exclusions, or alternative tool references, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions cleaning up cached handles but does not warn that released handles become invalid for subsequent operations, nor does it state anything about return values or side effects. This is a significant gap for a destructive cleanup operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and reason. It is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool with full schema coverage, the description covers the essential purpose and parameter. However, it lacks important contextual detail about the consequences of releasing handles (e.g., invalidating references), which an agent should know before invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'scope' parameter, including a clear description and enum values. The tool description adds no additional parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cleans up cached page/element handles ('清理缓存的 page / element 句柄') to prevent unbounded growth, providing a specific verb, resource, and rationale. This distinguishes it from sibling tools that query or manipulate pages/elements rather than managing handle lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use the tool: when handles might grow indefinitely ('防止句柄无限增长'). It does not explicitly mention exclusions or alternatives, but the context is clear enough for an agent to decide. The scope parameter further clarifies usage options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It discloses the core behavior (returns a page_id handle) but does not mention error conditions, whether it can return null, or any other behavioral traits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the tool's purpose and return type. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the essential information: what it retrieves and what it returns. However, it could be slightly richer about the context of page handles, but it's sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to clarify. With no schema fields to document, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current active page and returns a page_id handle. This is specific and distinguishes it from siblings like page_stack or page_size which query other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as page_stack or element_query. It simply states what it does, with no context on typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the default output (internal WXML) and the effect of includeSelf, which is useful. However, it does not explicitly state that the operation is read-only or describe the return format, potential errors, or any side effects. For a simple getter, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action and clearly explains the key option. Every word contributes meaning with no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two parameters and no output schema, the description covers the core functionality and the behavioral toggle. However, it does not elaborate on the return value beyond 'WXML structure', nor does it mention edge cases or error conditions. Given the tool's low complexity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for only 50% of parameters (includeSelf). The description partially compensates by mentioning includeSelf's effect, but it does not add meaning to element_id, which lacks a schema description. Since element_id is straightforward in context, the description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve the WXML structure of an element. It specifies the default behavior (internal WXML) and the includeSelf option, which distinguishes it from sibling tools like element_text or element_attribute. The verb '获取' (get) and resource '元素 WXML 结构' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description and tool name: use this to get WXML structure. However, it does not explicitly mention when to use this over alternatives or any exclusions. There is no clear guidance on scenarios where other element_* tools would be more appropriate, nor any prerequisites or side effects noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a state-changing action (restoring a method), but does not explain prerequisites (e.g., method must be mocked), error behavior, reversibility, or what happens if the method was not mocked. This lack of detail leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and target. Every word contributes meaning, with no redundancy or fluff. Appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, fully described in the schema, and no output schema. The description covers the core purpose. However, the lack of behavioral details (e.g., error conditions, idempotency) prevents it from being fully complete, though these are not critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required parameter 'method' with a clear description ('需要重置的 wx 方法名'). The tool description itself adds no parameter-specific information, but the schema already fully documents the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('恢复' / restore) and the target ('被 mock 的 wx 方法' / mocked wx method), specifying that it reverts to the original implementation. This distinguishes it from sibling tools like mock_wx_method and call_wx_method, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: after a wx method has been mocked, this tool restores the original implementation. While it doesn't explicitly state 'when to use' versus alternatives, the context is clear from the sibling tool mock_wx_method. It lacks explicit exclusions or alternative guidance, but for a simple revert operation, the implied usage is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the dual behavior (file save vs base64 return) but lacks specifics such as image format, file overwrite behavior, error handling, and whether 'current page' means full page or visible viewport. This is basic but incomplete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and explains the conditional behavior with no wasted words. It is optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one param and no output schema, the description explains the main behavior but omits what is returned when 'path' is provided, the image format, and the exact scope of the screenshot. This leaves gaps that could affect correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'path' parameter with the same meaning as the description ('图片保存路径，不传则返回图片 base64 编码'). The description adds no extra info beyond the schema's 100% coverage, so it meets the baseline but doesn't enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '对小程序当前页面截图' (take screenshot of current page of mini-program), using a specific verb and resource. It distinguishes itself from all sibling tools since none other involves capturing screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: passing 'path' saves to file, otherwise returns base64. This provides clear context on when to use each mode, though it doesn't mention alternatives because there are no direct siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 indicates a read-only retrieval operation and lists categories of information returned, but it does not disclose output format, potential limitations, or side effects. This is minimal but not misleading, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb, and uses examples to clarify scope. It is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description provides a basic understanding by listing example fields, but it does not fully specify the return structure or cover all potential fields. Since there is no output schema, the description falls short of being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema. According to the rubric, 0 params sets a baseline of 4. The description adds no parameter details because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches runtime environment system information, listing specific examples (device model, OS version, WeChat version). The verb '获取' (get) and resource are specific, and the tool is distinct from sibling tools focused on page/element operations or wx methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when system info is needed, but it does not explicitly provide when-to-use conditions or mention alternatives. No obvious sibling tool overlaps with this purpose, so the context is somewhat clear, but not explicit enough for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return type (array of element_id handles) and the important limit of 1000 handles, along with the behavior of keeping only the last 1000. This goes beyond the schema and provides useful behavioral context, though it does not explicitly mention read-only semantics or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes the core action, the scope (within element), the selector type, the return type, and the limit. Every word contributes relevant information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the key aspects: purpose, parameters, return value, and a critical limit. The lack of an output schema increases the burden to explain returns, which the description does. It omits minor details like empty array behavior and result ordering, but these are not critical for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for 'selector' (WXSS selector) but not for 'element_id'. The description clarifies that element_id refers to the element within which the query occurs, adding meaning to that parameter. However, it does not provide detailed syntax or examples for the selector, so the added value is moderate, given only 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: querying all matching child elements within an element using a WXSS selector. It distinguishes itself from sibling tools like element_query by explicitly saying 'all' and describing the return of an array of element_id handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the 'query all' semantics and the description mentions the tool operates on child elements, but it does not explicitly state when to use this tool versus alternatives like element_query or xpath variants. There is no exclusion or alternative naming, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the valuable trait that the ticket is valid for two hours, but does not mention whether the ticket is newly generated each time, whether it can expire, or what the return format is. Partial transparency is shown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, and includes a parenthetical detail about validity. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description conveys the core purpose and the two-hour validity, which is sufficient context for a simple tool. It could mention the relationship with refresh_ticket, but overall it provides adequate context for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter meanings since none exist. It adds no misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'get' and the resource 'developer tool login ticket', and adds a validity period. This distinguishes it from sibling tools like set_ticket and refresh_ticket, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a login ticket is needed, but provides no explicit guidance on when to use this tool versus alternatives like set_ticket or refresh_ticket. There are no exclusions or alternative recommendations, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior of overriding a wx method and returning a fixed result, which implies mutation. However, it lacks details on reversibility, scope, or side effects, leaving some uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It efficiently conveys the action, resource, and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is fairly complete. It explains what it does and why, and the schema documents the parameters. It could mention restoration or state persistence, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'method' and 'result' documented. The tool description essentially restates what the schema already provides, adding no extra meaning or syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '覆盖' (override), the resource 'wx 方法' (wx method), and the outcome '返回固定结果' (return fixed result). It also mentions the purpose '用于模拟第三方依赖' (to simulate third-party dependencies), which distinguishes it from sibling tools like call_wx_method and restore_wx_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating this tool is for simulating third-party dependencies, implying it should be used when mocking is needed. However, it does not explicitly mention alternatives or exclusions, such as when to prefer call_wx_method or restore_wx_method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the return format (array of element_id handles) and a critical behavioral limit (only last 1000 handles available when >1000). This goes beyond basic query behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence: main action first, then parenthetical return/limit detail. Every word contributes, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query tool with no output schema, the description covers purpose, return format, and a key limit. It does not explicitly mention potential errors or required permissions, but given the simplicity and sibling context, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with only selector having a description. The tool description adds little: it mentions 'in the page' to contextualize page_id but does not explain page_id format or semantics beyond that. Selector description in schema already says WXSS selector, and the description repeats that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: query all matching elements in a page using a WXSS selector, and specifies the return type. The 'all' in the name and description distinguishes it from page_query (first match) and XPath variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when all matches are needed) through the word '所有' (all), but it does not explicitly provide alternatives or when-not-to-use guidance. It offers no comparison to page_query or page_query_xpath_all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述本身明确披露了关键副作用“关闭所有页面”，这是重要的破坏性行为，提供了超越基本信息的行为透明度；但未提及返回值或权限要求，略有不完整。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述为单句，直接明确，信息密度高，无冗余内容，结构紧凑。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单，描述已涵盖核心行为（关闭全部页面并重开指定页面），但缺少与launch等工具的比较说明，在兄弟工具众多的上下文中略显不足，但整体完整度较好。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式中url描述覆盖率为100%（“需要打开的应用内页面路径”），描述本身未额外增加参数含义，依据高覆盖率的基线给予3分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确规定“关闭所有页面并重新打开指定页面”，动词明确（关闭、重新打开），资源具体（页面），且与launch/navigate_to等兄弟工具区分开来，清晰界定功能范围。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述隐含了使用场景（需要重置页面栈并打开指定页面），但未明确说明何时使用或何时不使用，也未对比launch、navigate_to等替代工具，因此仅为隐含的用法指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the URL prefix requirement, which is useful behavioral context beyond the schema. However, it does not mention side effects such as closing other pages or the result/return value, which could be expected for a navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that includes the core action and a key constraint. Every word contributes value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is sufficient: it states the purpose and the critical URL format. It does not mention output or side effects, but given the simplicity of the action and lack of output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (url has a description), so baseline is 3. The description adds the constraint that url must start with '/', which is not present in the schema's parameter description. This additional semantic guidance elevates the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: "切换到 tabBar 页面" (switch to tabBar page), with a specific resource type (tabBar page) and a scope constraint (URL must start with /). This distinguishes it from sibling navigation tools like navigate_to and redirect_to, which are for non-tabBar pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for switching to tabBar pages, and it provides a critical format constraint (url starts with /). However, it does not explicitly mention when NOT to use it or contrast with alternatives like navigate_to or re_launch, leaving the agent to infer from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two behavioral traits: automatic collection after connection and a maximum of 500 logs. It does not describe the return format, behavior when no logs exist, or whether logs are cleared after retrieval, leaving moderate gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence in Chinese. It front-loads the primary action ('获取'), then adds the two most relevant details (auto-collection and limit) without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers the core purpose and key constraints. However, it does not specify the exact return structure or nil/empty behavior, which would be expected given the lack of a structured output schema. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms an empty object. According to the rubric, the baseline for 0 parameters is 4, and the description does not need to compensate for any missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '获取' (get) and the resource '控制台日志' (console logs), adding specific context about automatic collection after connection and a 500-item limit. This distinguishes it from sibling tools like exception_messages, which target a different log type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '连接后自动收集' (automatically collected after connection) provides a clear precondition and timing for usage. However, it does not explicitly mention when not to use this tool or name alternatives, though the context is strong enough to guide a correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 two behavioral traits: logs are automatically collected after connection and limited to 500 entries. However, it does not explicitly confirm whether the operation is read-only or whether it clears logs, though '获取' implies a read. Some useful context is added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence in Chinese that conveys all essential information without redundancy. Every piece of content (purpose, connection requirement, limit) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is sufficiently complete for an agent to know what it does, when it can be invoked (after connection), and what to expect (up to 500 exception logs). The return type is implied by '获取' and the noun '日志'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100%. Per the calibration guidelines, 0 params gets a baseline of 4. The description adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves exception logs from the mini-program runtime, using a specific verb ('获取') and resource ('异常日志'). It also adds distinctive details (auto-collection after connection, 500-entry limit) that help differentiate it from sibling tools like console_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after connection (logs are automatically collected) and provides a context clue, but it does not explicitly state when to prefer this tool over alternatives like console_messages or clear_event_logs. No exclusions or alternative tools are mentioned, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return type (array of element_id handles) and an important behavioral limit: when more than 1000 matches, only the last 1000 handles are available. This adds meaningful context about the operation's cap, though it does not cover error cases or handle lifetime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core function (query all matching elements by XPath) and appends the critical return/limit behavior. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no output schema, the description covers the main behavior and the 1000-handle limit, which is useful. However, it does not explain what happens when there are no matches, whether the page must be active, or how the returned handles are used, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the xpath parameter with a description, and the tool description repeats 'XPath expression'. The phrase 'in the page' indirectly implies the page_id parameter refers to the target page, but no additional syntax or type details are provided. This is a modest compensation for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries all matching elements by XPath in the page, using specific verbs and resources. It also distinguishes from siblings by including 'all' and the XPath method, and specifying the return of element_id handle arrays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for querying all XPath matches, which differentiates it from singular XPath queries. However, it does not explicitly mention alternatives or when not to use it, so it lacks active exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It discloses a key side effect: closing the current page and replacing the stack top. This is important navigation behavior that agents need to know. It does not mention error conditions or prerequisites, but for a simple navigation tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the action front-loaded and the behavioral side-effects in parentheses. Every word earns its place, and no filler or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool with one parameter and no output schema, the description provides the core purpose, target page type, and behavioral side-effect. It is complete enough for an agent to select and invoke the tool correctly, though it lacks explicit edge-case or error handling notes, which are not essential for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for the single parameter 'url' with a description ('需要跳转的应用内非 tabBar 页面路径') that matches the tool description. Since schema coverage is 100%, the tool description adds no new parameter semantics beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '重定向到应用内非 tabBar 页面（关闭当前页面，替换栈顶）' clearly states the action (redirect), the target (in-app non-tabBar page), and key behavioral details (closes current page, replaces stack top). This distinguishes it from sibling tools like switch_tab, navigate_to, and navigate_back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for non-tabBar pages by explicitly stating '非 tabBar 页面', which contrasts with switch_tab (for tabBar pages). It also clarifies that it closes the current page and replaces the stack top, differentiating it from navigate_to (which pushes a new page) and navigate_back (which pops). However, it does not explicitly name alternatives or provide 'when to use vs when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the key behavioral detail that the expiration time resets to two hours, going beyond a tautological 'refresh'. It does not mention side effects like invalidating other sessions, but given the simplicity, it offers reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, with no wasted words. It clearly states the action and the effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully conveys the tool's behavior and outcome. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema. The description adds no parameter-specific information, but none is needed; the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'refresh' and the resource 'login ticket', and adds the specific effect 'expiration time reset to two hours', which distinguishes it from siblings like get_ticket and set_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a login ticket needs renewal but does not explicitly state when to use it over alternatives such as set_ticket, or when not to use it. No comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the important side effect (window remains open) and the primary action (disconnect). For a simple zero-parameter tool, this is adequate, though it could add details about reversibility or impact on ongoing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the action and adds only the essential behavioral caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully covers the purpose and the key distinguishing behavior. The sibling list shows overlap potential with 'close', and the parenthetical addresses that directly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('断开小程序连接' = disconnect mini-program connection) and adds a key behavioral qualifier ('开发者工具窗口保持打开' = developer tools window stays open). This distinguishes it clearly from sibling tools like 'connect' and especially 'close'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the window stays open, which implicitly tells the agent when to use this over 'close'. However, it does not explicitly name alternative tools or state when-not-to-use, so it misses some explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pureia/wechat-devtools-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server