ruyi-mcp

by Facetomyself

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.7
Disambiguation2/5
Multiple tools have overlapping purposes: ruyi_capture_start vs ruyi_intercept_requests vs ruyi_get_request_initiator all deal with network monitoring, and ruyi_human_move/click/drag overlap in behavior. Descriptions help but boundaries are fuzzy, causing likely misselection.
Naming Consistency3/5
All tools share the 'ruyi_' prefix and mostly use snake_case, but the verb/noun order is inconsistent: ruyi_websocket_inject and ruyi_human_move are noun_verb while ruyi_emulate_geolocation and ruyi_get_cookies are verb_noun. Some names like ruyi_break_on_xhr mix prepositions, deviating from the predominant pattern.
Tool Count1/5
59 tools is extremely high, far above the 50+ threshold even for a broad automation server. The count suggests significant redundancy (e.g., multiple capture/intercept and breakpoint tools) rather than a lean, well-scoped surface.
Completeness4/5
The tool set covers the major browser automation domains: navigation, DOM interaction, network capture/interception, breakpoints, human simulation, session export, and fingerprinting. Minor gaps exist (e.g., no direct window resize or full-page HTML retrieval, but these are workable via evaluate_script).
Average 3.6/5 across 59 of 59 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.json to 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 provided, the description carries the full burden of behavioral disclosure. It only states 'Click DOM element,' revealing nothing about side effects, waiting behavior, error conditions, or whether the click is a read-only operation. This is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, making it concise. However, it is so underspecified that it borders on a tautology, and there is no structured presentation of additional context that would justify this minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description is the only source of context, and it lacks essential information such as return values, success/failure behavior, element state requirements, or fallback actions. Given the large number of sibling tools, this level of minimalism is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'selector' but not 'pageIdx,' giving 50% coverage. The tool description adds no parameter information whatsoever, failing to explain the relationship between the two parameters or compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (click) and the target (DOM element), giving a specific verb+resource. However, it does not explicitly distinguish itself from sibling tools like ruyi_dom_select or ruyi_human_click, which also involve DOM interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, leaving the agent to guess when clicking a DOM element 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 the full burden of behavioral disclosure, but it only states the action without explaining side effects, persistence, page scope, or reversibility. It does not mention what happens after setting the timezone or whether it affects network requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. A single phrase is not enough for a tool with two parameters and potential side effects; it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and incomplete schema coverage, the description is far from complete. It does not clarify the effect of pageIdx, whether the emulation persists, or how it interacts with other emulation settings. A more detailed description is needed for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the timezoneId or pageIdx parameters. Schema coverage is only 50% (timezoneId documented, pageIdx missing), and the description does not compensate by explaining either parameter or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '模拟浏览器时区' clearly states a specific action (simulate) on a specific resource (browser timezone), distinguishing it from sibling emulation tools like geolocation or locale. However, it leaves ambiguity about whether the emulation applies to the whole browser or a specific page, given the pageIdx parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, nor any mention of prerequisites, effects on existing pages, or whether a page reload is needed. The description provides no contextual hints beyond the action itself.
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 burden for behavioral disclosure. It only states the action 'stop all network interception' but does not describe side effects, whether it clears pending interceptions, scope (global vs current page), or any impact on other interception-related tools. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence without fluff, so it is concise. However, it is under-specified: it omits essential details about parameters and usage, making it more of a minimal placeholder than a well-structured description. Conciseness cannot compensate for missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no annotations, the description should explain the overall behavior and parameter scope. It does not. The presence of sibling tools like ruyi_intercept_wait and ruyi_trace_stop suggests potential overlap or sequencing, but the description gives no context for how this tool fits into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter, pageIdx, with no description (schema description coverage is 0%). The tool description also fails to mention or explain pageIdx, leaving agents with no semantic information about what this parameter controls or how to use it. The description adds no value beyond the schema in this regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stop all network interception.' This is a specific verb+resource combination that unambiguously defines the tool's function. It distinguishes itself from sibling tools like ruyi_intercept_requests and ruyi_intercept_responses by targeting the stopping action rather than starting or waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as ruyi_trace_stop or ruyi_capture_stop, nor does it explain any prerequisites (e.g., that interception must already be active). The optional pageIdx parameter is not described, so an agent cannot know its purpose or when to set 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?
The description adds Chinese translations for the enum values (e.g., '跳过缓存' for bypass) but does not disclose side effects, persistence, whether it affects current or future navigations, or how pageIdx influences behavior. With no annotations, the description carries the full burden, and it fails to provide substantive behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. There is no redundancy, and the mode options are listed compactly. It could benefit from a structured breakdown, but it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a state-changing browser operation with no annotations or output schema, the description is incomplete. It omits pageIdx semantics, when to set cache behavior, interactions with cache-clearing tools, and whether the setting applies to the current page or future navigations. This is a significant gap for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; pageIdx has no description and the description does not mention it. The description glosses the mode enum values (default, bypass, force_cache) with Chinese meanings, adding some value, but it leaves pageIdx completely unexplained and fails to fully compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '控制浏览器缓存行为' (control browser cache behavior), and lists the three modes. It is specific about the resource (browser cache) and action (control/set), distinguishing it from siblings by focusing on cache behavior rather than navigation or data clearing, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ruyi_clear_site_data or navigation tools. The description only lists the modes without context on which scenario each mode suits or prerequisites.
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?
Without annotations, the description carries the full burden of disclosure. It adds useful selector format examples but does not explain the return value, error behavior when the element is not found, or whether the timeout parameter triggers a wait. The timeout is present in the schema but its behavioral implication is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact format list. It is front-loaded with the core purpose and contains zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what the tool returns (element information, handle, etc.) and what happens if the selector does not match. It also leaves pageIdx unexplained. For a tool used to locate elements for subsequent interactions, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description supplements the schema with concrete selector format examples (e.g., '#id', 'css:.class', 'xpath://div'), which adds meaning. However, the pageIdx parameter has no description in either schema or description, and the timeout behavior is only implied. Schema coverage is 67%, so the description provides some but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool locates DOM elements in the page, which is a specific verb+resource. It lists multiple selector formats, making its role as a locator distinct from action-oriented siblings like ruyi_dom_click or ruyi_dom_input, but it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 other DOM tools (ruyi_dom_get_info, ruyi_dom_click, etc.). The description implies it is for locating, but does not clarify that it should be used before actions or how it relates to alternatives.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It merely states what the tool does but gives no insight into side effects (e.g., does it persist, affect future navigations, or require reload?), scope, or any potential caveats. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose. It is appropriately sized and front-loaded with the most relevant information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no annotations or output schema, this description is too sparse. It does not clarify the meaning of pageIdx, what result to expect, or how this differs from related tools. The overall context is incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'locale' parameter but leaves 'pageIdx' undeclared. Schema description coverage is 50%, and the description adds no additional parameter information. The tool description fails to explain the role of pageIdx, so the agent cannot fully understand how to use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (模拟/emulate) and resource (browser language/region). It distinguishes itself from sibling emulate tools like ruyi_emulate_geolocation or ruyi_emulate_timezone by specifying exactly what is emulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. There is no mention of scenarios like testing internationalization or how it interacts with page navigation. The description lacks any usage 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 provided, the description carries the full burden of disclosing behavior. It only mentions the output (scriptId and content summary) and does not state whether the operation is read-only, requires an active browser, or has any side effects. The verb 'list' implies read-only, but this is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the primary action and result. Every word adds value, and there is no unnecessary filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple purpose but includes an undocumented parameter that suggests paging or filtering. The description lacks explanation of this parameter and does not provide enough contextual detail (e.g., whether it operates on the current page or across the session). The absence of an output schema is partially mitigated by the mention of scriptId and summary, but overall completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'pageIdx' with a default of 0 and no description in the schema. The description does not mention this parameter at all, leaving its meaning and purpose completely unexplained. With 0% schema description coverage, the description fails to compensate, providing no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all injected preload scripts with scriptId and content summary, which is a specific verb+resource scope. It differentiates from siblings like 'ruyi_list_scripts' by specifying 'preload' scripts, 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 Guidelines2/5
Does 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 (e.g., 'ruyi_list_scripts') and does not mention any exclusions or prerequisites. Usage is only implied from the purpose, but there is no explicit context or comparison.
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 the action without addressing side effects, return values, behavior if the breakpoint does not exist, or irreversibility. This is a significant gap for a removal operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff, and it is front-loaded with the action. It is appropriately brief, though it lacks a structured format that could include usage context. Still, the conciseness is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool, the description is incomplete. It does not explain the role of pageIdx, what the return value or success indication is, or whether the breakpoint must exist beforehand. Given no annotations and no output schema, the description is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter information. The schema provides a description for breakpointId (noting it comes from ruyi_list_breakpoints), but pageIdx remains undocumented in both the schema and description. With 50% schema coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移除指定软断点' clearly states the action 'remove' and the resource 'specified soft breakpoint'. This distinguishes it from sibling tools like ruyi_set_breakpoint_on_text and ruyi_list_breakpoints by the unique verb-resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or how it relates to alternatives. It does not mention that breakpointId should come from ruyi_list_breakpoints or that removal should complement breakpoint-setting tools. No usage context or exclusions are given.
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?
With no annotations provided, the description carries the full burden of explaining behavioral traits. It merely says 'switch active tab' without disclosing side effects (e.g., changing the current working page for other ruyi tools), error behavior for invalid indices, or whether it focuses the browser window. This is a significant gap for a state-changing 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It conveys the core purpose immediately and efficiently, earning full marks for conciseness and structure despite being minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no annotations, and no output schema, the description is too sparse to be complete. It lacks essential context about how the active tab selection affects subsequent operations, the need to call ruyi_list_pages first, and potential error conditions. The schema covers the parameter but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (pageIdx is described as '标签页索引'). The description adds no additional meaning beyond the schema, so the baseline of 3 applies. The parameter's role is clearly defined in the schema, but the tool description does not elaborate on how the index maps to tabs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '切换活跃标签页' (switch active tab) clearly states a specific action on a specific resource. It distinguishes itself from sibling tools like ruyi_list_pages (list), ruyi_new_page (create), and ruyi_close_page (delete) by focusing on selecting/activating an existing tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing pages), relationship to ruyi_list_pages for obtaining the index, or scenarios where one would choose this over ruyi_navigate_page.
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 transparency. It discloses that the tool stops tracing and returns a summary/data, but it omits important details such as side effects (e.g., whether traces are cleared), error handling, or requirements like an active trace session. This is a minimal disclosure that leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the core function without unnecessary words. It is well-structured and front-loaded, though it could add a brief note about the parameter or prerequisites without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature (one optional parameter) but lacks annotations, output schema, and parameter descriptions. The description covers the basic purpose but does not explain the pageIdx parameter, clarify the relationship to ruyi_trace_get_results, or address edge cases. This is insufficient for an agent to use the tool confidently in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single optional parameter 'pageIdx' with no description (0% schema coverage). The tool description also omits any explanation of this parameter, leaving the agent unable to infer what value to provide or how it affects the stop operation. The description must compensate in this case but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('stop BiDi tracing') and its result ('return summary and data'). This distinguishes it from sibling tools like ruyi_trace_start (which starts tracing) and ruyi_trace_get_results (which likely retrieves results while tracing is active).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to end an ongoing tracing session and retrieve results, but it does not explicitly state when to use it versus ruyi_trace_get_results, nor does it mention prerequisites or behavior if no trace is active. Usage context is implied but not fully specified.
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 notes that the tool overrides navigator.userAgent, but does not explain scope (e.g., per-page vs global), persistence across navigations, or how to reset the user agent. This 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short clauses that deliver the core purpose without any wasted words or repetitive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having two parameters and no output schema, the description is minimal. It does not explain the effect scope (curent page or all pages), relationship to pageIdx, or how the emulation interacts with browser navigation or other tools. This is insufficient 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only userAgent is described, pageIdx is not). The description does not mention parameters at all, so it adds no meaning beyond the schema. The meaning of pageIdx (likely page index) is left unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a browser UserAgent string and specifically overrides navigator.userAgent. This is a specific verb+resource that distinguishes it from sibling emulation tools like ruyi_emulate_geolocation, ruyi_emulate_timezone, and ruyi_emulate_locale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The sibling tools include other emulation functions, but the description doesn't differentiate usage 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?
无任何注解，描述需承担全部行为说明责任。但描述仅说明'读取'和'筛选'，未提及是否返回历史全部消息、分页行为、是否有副作用或是否需要特定页面上下文。这些信息对安全调用至关重要，描述未覆盖。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅有两句话，直接传达核心功能与筛选能力，没有冗余内容，信息密度高。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
没有输出schema，描述未说明返回格式或消息内容，但参数schema完整。缺少使用场景、返回值说明以及与其他日志工具的关系，对于简单列表工具尚可，但仍有明显提升空间。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema覆盖100%，每个参数均有描述。描述中的'按类型筛选'与types参数对应，但未额外补充参数语义或格式，因此达到schema覆盖下的基线3分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述使用具体动词'读取'和资源'浏览器控制台日志消息'，清晰说明工具功能。虽然未显式与兄弟工具如ruyi_get_websocket_messages、ruyi_list_network_requests进行区分，但资源本身具有特异性，足以与其他工具识别。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It discloses the two output modes (file or base64) and the PNG format, but does not mention the fullPage parameter's effect on capture scope or the pageIdx parameter, which are relevant behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the purpose and then add output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple screenshot tool, the description covers the core function and output options, but it omits pageIdx semantics and return value structure. Since there is no output schema and no annotations, these gaps make it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with filePath and fullPage already described. The description only reiterates the filePath behavior without adding new meaning, and it completely ignores pageIdx, which lacks a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: taking a screenshot of the current page, with options to save to file or return base64 PNG. However, it does not explicitly differentiate from sibling tools like capture_start, though the function is easily inferred from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the action itself without context, exclusions, or alternative tool references.
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 responsibility for disclosing behavioral traits. It only states 'simulate' but does not explain scope (current page vs. all pages), persistence, reversibility, or any side effects on the browser environment. This is insufficient 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a clear subject and action. It is front-loaded and contains no redundant information, exemplifying efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description is too sparse to be contextually complete; it fails to mention which page (pageIdx) is affected, how accuracy is applied, or what happens after emulation (e.g., reset behavior).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params have descriptions). The description merely repeats latitude/longitude and adds no extra meaning for pageIdx or accuracy. Since the schema already covers most params, the baseline is 3, and the description neither improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to simulate browser geolocation with latitude/longitude. The verb '模拟' (simulate) is specific, and the resource '浏览器地理位置' (browser geolocation) differentiates it from sibling emulation tools like timezone, locale, and useragent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other emulation tools or real geolocation methods. There are no prerequisites, context cues, or exclusions, leaving the agent to infer the appropriate usage scenario.
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 responsibility. It only mentions the trajectory algorithm but does not disclose click behavior details, potential side effects, failure conditions, or the effect of the algorithm choice. This is insufficient for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff, achieving efficiency. However, it is slightly too sparse to earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and no output schema. The description only covers the core purpose and algorithm, leaving parameter semantics and behavioral context incomplete. It is minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%. The description adds some meaning to the algorithm parameter by explaining it generates natural trajectories, but target and pageIdx remain unexplained. It does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a human mouse click and uses windmouse/bezier algorithms for natural trajectories. It distinguishes itself from sibling tools like ruyi_dom_click by emphasizing human-like behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when human-like click behavior is needed, but it does not explicitly compare with alternatives such as ruyi_dom_click or state when not to use it. The context is clear but lacks explicit exclusions or alternative guidance.
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 of behavioral disclosure. It only restates the basic action without mentioning scope (which frames/pages), return format, result limits, or behavior when nothing matches. This is insufficient for an agent to understand side effects or expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of fluff. However, it is so brief that it sacrifices necessary detail, making it efficient in form but not fully adequate as standalone guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is expected to cover scope, return values, and parameter behavior. It does neither, leaving important context missing for a tool with six parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no meaning beyond the existing query parameter description. The parameters isRegex, pageIdx, and caseSensitive are left undocumented in both the description and schema, forcing the agent to guess from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for a string or regular expression in the page's loaded JS source code. This specific verb+resource combination distinguishes it from sibling tools like ruyi_list_scripts and ruyi_get_script_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to locate a pattern within JavaScript sources already loaded in the page. However, it provides no explicit guidance on when to prefer this tool over alternatives such as fetching script sources with ruyi_get_script_source or setting breakpoints.
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 disclose side effects. It only states that headers are added to all future requests, but fails to mention whether the change is persistent across navigation, how to clear/reset headers, whether existing headers are overridden, or if it applies to all frames/websocket requests. This is a significant transparency gap for a stateful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: one for core behavior and one for typical use cases. It is front-loaded and efficient, with no wasted words. However, it could benefit from expanding on critical caveats without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, the absence of an output schema, and the presence of a potentially stateful operation, the description is insufficient. It does not explain the lifecycle of added headers (e.g., how to revert), the meaning of 'pageIdx', or any side effects on request/response interception, making it incomplete for autonomous decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 50% of parameters: 'headers' is described, but 'pageIdx' has no description. The tool description does not compensate for the missing 'pageIdx' semantics, leaving an agent without guidance on how to use it. The description adds minimal value beyond the schema for the headers parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('附加' / 'attach') and clearly states it applies to all subsequent HTTP requests. It also gives concrete use cases (auth token, custom UA), which helps distinguish it from cookie-related siblings like ruyi_set_cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases ('用于注入认证 token、自定义 UA 等') but does not explicitly mention when not to use it or contrast with alternative tools like ruyi_emulate_useragent, which also handles custom UA. This could cause ambiguity for an agent choosing between 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?
No annotations are provided, so the description must disclose behavior. It only mentions URL filtering, which is also in the schema. It does not state whether this is a read-only operation, how dynamic scripts are handled, or what the return format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence front-loads the main action. No filler words; the filtering capability is stated directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description omits explanation of the 'pageIdx' parameter and the expected return structure. Since there is no output schema, more detail would be helpful. However, the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the 'filter' parameter with a description, but 'pageIdx' has no description and the description text does not elaborate it. With 50% coverage, the description fails to compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('JavaScript script URLs'), and the scope ('loaded in the page'). It distinguishes from sibling tools like ruyi_list_preload_scripts by specifying loaded scripts, and from ruyi_get_script_source which retrieves source code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing script URLs but does not explicitly state when to use this tool over alternatives like ruyi_get_script_source or ruyi_search_in_sources. No exclusions or conditions are provided, so it relies on the agent inferring the appropriate 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?
The description discloses that omitting the 'name' parameter clears all cookies, which is a significant behavioral trait. However, with no annotations provided, the description carries the full burden and does not mention other important details such as whether cookies are cleared only for the current site or all domains, or whether the action is reversible. It adds some context but not comprehensive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It conveys the essential behavior without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cookie deletion tool with no output schema and no annotations, the description covers the main behavior and default case. However, it could be more complete by noting the destructive nature or scope of the deletion. It is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters with 100% coverage. The description restates the 'name' parameter's default behavior ('不传则清除全部') without adding new meaning. The pageIdx parameter is not mentioned in the description, though the schema describes it as a tab index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes cookies, with a specific verb and resource. It mentions the default behavior of clearing all cookies when no name is provided. However, it does not explicitly differentiate from sibling tools like ruyi_clear_site_data or ruyi_set_cookies, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 compared to alternatives such as ruyi_clear_site_data or ruyi_set_cookies. The description only explains the basic operation and default behavior, without stating prerequisites or 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.
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 states a read operation but does not disclose return format, error behavior, whether it works on hidden elements, or whether it blocks until the element exists. The read-only nature is only implied by the verb 'read'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the primary action and object. It contains no redundant or filler content, every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too sparse to fully understand the tool's behavior. It does not explain the structure of the returned data, what happens when the selector matches no elements, or how pageIdx affects the operation. For a tool with three parameters and no output schema, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes selector and attribute, and the description adds context that multiple data types (text, HTML, form values) are retrievable. However, pageIdx is not described in either the schema or the description, and the interplay between the attribute parameter and the other data types remains unclear. Schema coverage is 67%, so description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (read) on DOM elements, listing the exact data types: text content, HTML, form values, and attributes. This distinguishes it from sibling DOM tools like ruyi_dom_click, ruyi_dom_input, and ruyi_dom_select, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving DOM element information but does not explicitly state when to choose this tool over alternatives like ruyi_evaluate_script or ruyi_dom_select. No exclusions or when-not-to-use guidance is provided, leaving usage to be inferred from the action verb and listed data types.
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 disclose behavioral traits but only states the basic action. It does not mention default clearing behavior, event dispatch, file upload limitations, or any effects on the page beyond the input itself. The 'clear' parameter in the schema is the only behavioral hint, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and immediately clarifying the upload capability. Every word earns its place with no unnecessary details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations, making the description the sole source of contextual information. It is too brief to cover important behaviors like clearing by default, event dispatch, or how file uploads work, and it does not mention the 'pageIdx' parameter at all. An agent would need more context to invoke this tool reliably in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by clarifying that the 'text' parameter can be either a normal text string or a file path for upload, which goes beyond the schema's basic description. However, it does not explain 'pageIdx' or 'clear', though schema coverage is 75% and those fields have their own descriptions. The added upload semantics justify a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool inputs text or uploads files to DOM elements, explicitly mentioning support for both regular text and file path upload. This distinguishes it from sibling tools like ruyi_human_input, which simulate human input rather than direct DOM manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 ruyi_human_input or other DOM interaction tools. The description only lists capabilities without providing context, exclusions, or recommended scenarios, leaving the agent to infer 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 provided, the description carries the full burden. It does disclose the extension behavior (JSON results use .json, others use .js), which is a useful behavioral trait. However, it does not mention overwrite behavior, file system permissions, or side effects like creating directories. Basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, highly concise and front-loaded. The main action is stated first, followed by a specific formatting rule. No superfluous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers its core function and output naming. However, it leaves pageIdx unexplained and does not provide context about when to use it (e.g., what 'script' refers to, how pageIdx relates to scripts). Given the sibling tools, a brief usage note would improve completeness, but the description is acceptable for a basic save operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (url and filePath have descriptions), but the description itself adds no parameter-specific details. The pageIdx parameter is entirely undocumented in both schema and description, and the description does not elaborate on how url or filePath are used beyond their schema descriptions. The extension rule is about output, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('保存' - save), the resource ('脚本完整源码' - complete script source), and the destination ('本地文件' - local file). This distinguishes it from sibling tools like get_script_source or list_scripts by focusing on the save-to-file behavior. The addition of extension rules (JSON → .json, others → .js) further specifies the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_script_source, list_scripts). There are no prerequisites mentioned, such as needing a page context or ensuring the script exists. The description is purely functional without context about scenarios or constraints.
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 that interception starts, filtering is supported, and consumes via wait, but does not mention side effects, whether interception replaces existing sessions, or how to stop. It partially compensates but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. The sentence about future versions is slightly unnecessary but not verbose. Overall, every sentence contributes, though the future note could be omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the core workflow (start interception, consume with wait), but lacks information on stopping (ruyi_intercept_stop exists), behavior if already intercepting, and return value. For a stateful tool, this is incomplete but serviceable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only urlPatterns has a description. The description mentions URL filtering but does not explain pageIdx at all. This leaves a significant semantic gap for the pageIdx parameter, which is undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts intercepting HTTP requests at the beforeRequestSent stage, with a specific verb and resource. It distinguishes from sibling tools like ruyi_intercept_responses by specifying request interception and its primary workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting intercepted requests are consumed via ruyi_intercept_wait, but it does not explicitly contrast with alternatives such as ruyi_intercept_responses or explain when not to use this tool. The context is clear but lacks explicit exclusions or alternative guidance.
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 notes that data can be saved to a file, but does not state whether the tool is read-only or modifies browser state, nor does it describe file-writing behavior such as overwriting or permissions. This leaves meaningful uncertainty about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the action and data types front-loaded. The final sentence about being the core tool is mildly redundant but still provides context, making it appropriately sized overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should clarify the structure of the returned JSON, which it does not. It also omits prerequisites such as a currently attached browser. It covers the basic purpose and save option but lacks these important details for full usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since each parameter has a description, so the baseline is 3. The description adds minimal extra meaning, only mentioning UserAgent and URL as part of the export even though they are not in the default 'include' list, which is useful but ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the current browser session state and enumerates specific data (Cookie, localStorage, sessionStorage, UserAgent, URL). It distinguishes itself from siblings like ruyi_get_cookies by covering the full session rather than individual components, and it explicitly mentions the cross-tool reuse purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the tool's role as a core session-bridging utility for js-reverse-mcp, ruyitrace, and others, providing clear use-case context. However, it does not explicitly contrast with alternative tools or state when not to use it, so it stops short of full exclusion guidance.
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 of behavioral disclosure. While 'get' clearly implies a read-only operation, the description does not elaborate on return format, whether cookies from all domains are included, or any edge cases. It adds minimal context beyond the action itself, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that fully captures the tool's purpose. It contains no superfluous information and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one optional parameter, and the description clearly states its function. There is no output schema, but 'get cookies' implicitly conveys the return value. The lack of information about return format or edge cases is acceptable given the low complexity and strong schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning the single parameter pageIdx is already documented as '标签页索引' (tab index). The tool description adds no additional parameter semantics. According to the rubric, a baseline of 3 is appropriate when schema covers all parameters and the description does not compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('获取' meaning 'get') and a clear resource ('当前页面的所有 cookies' meaning 'all cookies of the current page'). This clearly distinguishes it from sibling tools like ruyi_set_cookies and ruyi_delete_cookies, which perform different cookie operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios for cookie reading vs writing, nor does it reference related tools like ruyi_set_cookies, ruyi_delete_cookies, or ruyi_clear_site_data. There is no explicit usage 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the two access modes but does not explain what happens if both modes are specified, how pageIdx works, what the return format is, or how errors are handled. This is a significant gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose and key capabilities without any wasted words. Every element 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, two selection modes, and no output schema, the description is too sparse. It does not clarify when to use offset vs. line numbers, what pageIdx does, or what the response structure looks like. This leaves the agent with many unanswered questions for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, which is high, but the description adds a conceptual model by categorizing parameters into 'line number range' (startLine, endLine) and 'character offset' (offset, length) modes. This goes beyond the individual schema descriptions, giving the agent a better mental model for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a source code snippet for a specified URL, with support for line-number ranges or character offsets. This specific verb+resource+scope distinguishes it from siblings like ruyi_list_scripts, ruyi_save_script_source, and ruyi_search_in_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the two selection modes (line range vs. character offset), but provides no explicit guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. It leaves the user to infer the appropriate context from the schema.
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 mechanism (BiDi lookup and click) and mentions bypassing closed shadow root, which is useful. However, it does not disclose failure modes, side effects, requirements (e.g., BiDi connection), or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second explains the mechanism. No redundant wording or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; the description does not mention expected return values, behavior when no Turnstile exists, or how pageIdx affects operation. The tool is moderately complex, so these gaps make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes timeout and checkInterval but not pageIdx. The description adds no parameter details, leaving pageIdx unexplained. With 67% schema coverage, the description could have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool automatically handles Cloudflare Turnstile verification, distinguishing it from sibling browser automation tools. The mechanism ('BiDi', 'iframe click') adds specificity beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when Cloudflare Turnstile verification is encountered, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion criteria or alternative tool references are provided.
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 'list' implies a read-only operation, which is a key behavioral trait, but no additional details are given about side effects, prerequisites, or whether breakpoints are modified. It meets the minimal bar but lacks richer 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the complete purpose without any wasted words. It is perfectly concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is largely adequate, but it omits any mention of the return format or any prerequisites. Since there is no output schema, the description should carry this information, making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameters. The baseline for zero parameters is 4, and the description appropriately focuses on the tool's action and scope without adding irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all currently active soft breakpoints' uses a specific verb ('list') and clearly identifies the resource (soft breakpoints). It distinguishes itself from sibling breakpoint tools like `ruyi_set_breakpoint_on_text` and `ruyi_remove_breakpoint` by focusing on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states the function without any context about prerequisites, such as being attached to a browser, or when one might need to list breakpoints.
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 output scope and that it includes nested frames, and 'list' implies read-only. However, it does not explicitly state that it has no side effects, nor does it clarify how 'current page' interacts with the pageIdx parameter, leaving ambiguity about which page is actually inspected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese that packs the key information: scope (current page), inclusion of nested frames, and specific return fields. Every element earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description covers the main behavioral aspects. However, it leaves the relationship between 'current page' and pageIdx ambiguous, and it does not mention that the returned contextId is useful for subsequent operations like select_frame. These are notable gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as pageIdx has a description ('标签页索引'). The tool description does not add extra semantics beyond the schema; it refers to 'current page' without tying it to the pageIdx parameter, which could confuse whether pageIdx overrides 'current' or selects which page's frames to list. The baseline of 3 is appropriate because the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all iframes/frames in the current page, including nested ones, and specifically enumerates the returned fields (contextId, url, isCrossOrigin). This is a specific verb+resource combination and distinguishes it from sibling tools like select_frame or list_pages by focusing on frame enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting all frames in the current page, but it does not explicitly state when to prefer this over alternatives like ruyi_select_frame, nor does it exclude cases where other tools are more appropriate. There is no 'use when' or 'instead of' guidance, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description carries the full burden of behavioral disclosure. It states the input format but does not mention whether cookies are merged with or replace existing ones, whether the operation targets the page indicated by pageIdx, or any persistence/scope details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise Chinese sentences, front-loaded with the core operation. It contains no redundant or filler content, and every sentence adds useful input-format detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the input structure well but lacks behavioral context such as overwrite/merge semantics, tab targeting via pageIdx, and any side effects. It is minimally acceptable for a simple setter but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly requires 'name' and 'value' in each cookie object and enumerates optional fields (domain, path, secure, httpOnly, sameSite, expiry), going beyond the schema's abbreviated 'domain?, path?, ...'. While pageIdx is not mentioned in the description, the schema provides its meaning, maintaining adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '设置 cookies' (set cookies), which is a specific verb+resource pair, and further explains the required cookie object array. This clearly distinguishes it from sibling tools like ruyi_get_cookies, ruyi_delete_cookies, and ruyi_clear_site_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives is provided. The intended usage is only implied by the tool's name and description; there is no mention of when not to use it or references to sibling cookie-related tools.
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 does reveal a key behavior (does not stop trace) and the return type, but it omits whether a trace must be active, whether it consumes entries, or any error conditions. This is useful but incomplete for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two short sentences, front-loaded with the primary purpose and a key behavioral distinction. No filler or redundant phrases; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must provide necessary context. It omits critical information such as whether a trace must be started first, how pageIdx works, and what happens if no trace is active. For a paginated getter, this is too incomplete for an agent to use fully correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with only 50% description coverage: limit is described but pageIdx is undocumented. The tool description itself does not mention either parameter or explain pagination, failing to compensate for the undocumented pageIdx. An agent receives no guidance on how parameters affect results beyond the schema's partial limit description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (get) with a clear resource '追踪结果' (trace results), and explicitly states it does not stop tracing, distinguishing it from ruyi_trace_stop. It also specifies the return content as recent BiDi event entries, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '不停止追踪' (without stopping tracing) clearly signals the tool is for retrieving current results while tracing remains active, implying a distinct use case from ruyi_trace_stop. However, it does not explicitly name alternatives or provide when-not-to-use scenarios, so it stops short of a fully explicit guideline.
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 of behavioral disclosure. It reveals that capture is passive, filters by URL pattern, and results are fetched later. However, it does not mention side effects, scope (e.g., pageIdx), or whether previous captures are replaced, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action, and contains no filler. It efficiently conveys the core purpose and next step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 covers the essential start-and-wait workflow, but it omits how to stop capture (ruyi_capture_stop) and fails to clarify the pageIdx parameter. This is adequate but not fully complete for a tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'method' and 'pattern', but the description only restates the pattern matching concept and adds no new parameter details. The 'pageIdx' parameter is undocumented in both the schema and the description, which is a notable gap for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '开始被动抓包' (start passive packet capture), and scopes it by URL pattern matching. It also names the follow-up tool ruyi_capture_wait, distinguishing it from siblings like ruyi_capture_stop and intercept tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage flow: start capture, then use ruyi_capture_wait to retrieve results. It does not explicitly compare with interception tools, but the '被动' (passive) qualifier implies non-modifying observation, giving clear context.
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?
无注解，描述需承担行为透明度责任。它清楚列出了清除的具体内容（Cookie、localStorage、sessionStorage）和范围（当前页面），提供了基本且有用的行为信息。但未说明清除操作不可逆、是否触发页面刷新等额外效果。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
一句话，直接明了，没有冗余信息，信息密度高，符合前端加载原则。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于简单清除工具，描述基本够用，但缺少对pageIdx参数的解释，也未说明清除后是否影响iframe或需要刷新页面。在无注解和输出schema的情况下，这些空白影响整体完整性。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
唯一参数pageIdx在schema中无描述，描述中也未提及。虽然'当前页面'可能暗示与页面索引相关，但未明确解释如何选择页面或默认行为，参数语义完全依赖猜测。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述使用明确动词'清除'和资源'当前页面的浏览器状态'，并列出了Cookie、localStorage、sessionStorage，清晰说明了工具功能。与仅删除Cookie的ruyi_delete_cookies等兄弟工具区分明显。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述隐含了使用场景（清除当前页面的所有浏览器状态），但未明确何时使用本工具而非替代方案（如ruyi_delete_cookies只清理Cookie）。没有提及排除情况或前置条件。
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 the clear parameter's effect (clearing the buffer after reading) and the return structure (url, sent, received, timestamps). However, it doesn't mention whether reading is destructive by default (implied by clear=false), prerequisites beyond injection, or what happens if no messages exist. It adds some value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the main purpose and return data, the second explains the clear parameter. Every sentence contributes value, and the most critical information is front-loaded. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters (one undocumented), no output schema, and no annotations. The description covers the core function and return format but leaves pageIdx unexplained and does not specify the exact structure of the message lists. It gives a high-level overview but is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only clear has a description, and pageIdx is undocumented. The tool description only explains clear (redundant with the schema's description) and does not provide any meaning for pageIdx. Since the schema description coverage is low, the description was expected to compensate, but it fails for a significant parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve WebSocket messages collected after Proxy injection. It specifies the resource (WebSocket messages), the verb (获取/get), and the return content (per-connection URL, sent, received lists, and timestamps), distinguishing it from siblings like ruyi_list_network_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: use it after proxy injection ('已注入 Proxy 后'). It implies the prerequisite of having injected the proxy first. It does not explicitly name alternatives or exclusions, but the context is sufficient for basic usage.
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 of behavioral disclosure. It reveals queue mode (each call returns one), timeout behavior (timedOut=true), and the return fields (url, method, headers, body, responseStatus). The verb '消费' implies the item is removed from the queue, which is a useful side-effect disclosure, though it does not mention what happens if no interception is active or if the queue is empty beyond timeout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('等待并消费一个拦截到的请求/响应'), then covers queue mode, timeout, and return fields in a compact format. Every clause adds meaningful information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the main behavior (wait/consume, queue, timeout, return fields) but lacks important contextual details such as prerequisites (e.g., needing to call ruyi_intercept_requests first) and the meaning of pageIdx. The lack of annotations means the description is the only source of safety and interaction context, and while it covers core aspects, the missing pieces limit completeness for an agent deciding whether and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 50%, with pageIdx lacking any description, and the tool description does not explain pageIdx at all. While the timeout parameter is described in the schema and its behavior is echoed in the tool description, the description fails to add meaning for pageIdx, leaving an undocumented parameter that the schema alone does not clarify. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for and consumes an intercepted request/response, using the specific verb '等待并消费' with a clear resource. It also distinguishes this tool from siblings like ruyi_intercept_requests (which sets up interception) by focusing on the retrieval/consumption aspect, and the queue mode ('每次调用返回一个') further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through '队列模式：每次调用返回一个' and the timeout behavior, suggesting it should be called repeatedly to consume queued items. However, it does not explicitly state when to use this tool versus alternatives like ruyi_capture_wait or mention prerequisites such as setting up interception first, so the guidance 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?
No annotations are provided, so the description carries the full burden. It discloses the key side effect of injecting debugger, but does not mention whether breakpoints are persistent, how they interact with existing breakpoints, or any prerequisites. The equivalence to another tool adds some clarity but leaves gaps in behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and followed by a useful equivalence note. Every sentence earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but without annotations or an output schema, the description leaves gaps: pageIdx is unexplained, and the description does not mention whether breakpoints are persistent or how they are managed. It is adequate for basic understanding but an agent may need to consult sibling tools or additional context to fully use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: url is described as a substring match, but pageIdx has no description. The description only reinforces the URL matching behavior and does not compensate for the undocumented pageIdx parameter. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a breakpoint (injects debugger) when XHR/Fetch request URLs match, with a specific verb and resource. It also distinguishes itself from the sibling tool ruyi_set_breakpoint_on_text by describing itself as an XHR wrapper, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names an alternative tool (ruyi_set_breakpoint_on_text) and explains this is the XHR-specific variant, giving clear context on when to use it. It doesn't explicitly state when not to use it, but the equivalence provides sufficient guidance for 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?
With no annotations, the description carries the full burden for behavioral disclosure. It adds a valuable constraint that the main tab cannot be closed, but does not explain what happens when attempting to close it, whether the operation is permanent, or other side effects. Some context is provided, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an essential note. It is front-loaded, contains zero waste, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core purpose and the critical exception. However, it lacks details on response/behavior for invalid inputs (e.g., out-of-range index) and could be more complete for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes pageIdx as the index of the page to close (100% coverage), so baseline is 3. The description goes beyond the schema by stating that pageIdx=0 is invalid, which is a meaningful parameter constraint that helps the agent avoid errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes a specified tab/page with a specific verb ('close') and resource ('page'). It distinguishes from sibling tools like new_page, select_page, etc., and adds a critical constraint about pageIdx=0.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to close a page, and provides an explicit limitation (cannot close pageIdx=0). However, it does not explicitly mention when to use alternatives or when this tool should be avoided beyond the main tab restriction, so context is implied rather than fully 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?
No annotations are provided, so the description carries the full burden. It reveals that the tool simulates human-like movement and supports bezier/windmouse algorithms, but it does not disclose mechanics such as whether events are injected at OS level, whether target needs to be visible, or what happens on failure. This is useful but incomplete behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and target. Every sentence adds useful information: purpose, supported algorithms, and the anti-detection context. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover return behavior and side effects, but it does not mention what the tool returns, whether it blocks, or prerequisites. For a relatively simple action it is adequate at a high level, but leaves operational details implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with target, style, and algorithm described in the schema. The description reinforces the target and names the algorithm values (bezier, windmouse) but adds no meaningful detail about the 'style' enum values or 'pageIdx' parameter. It provides slight added context but largely duplicates schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb and resource: '模拟人类鼠标移动到目标元素' (simulate human mouse move to target element). It is distinct from sibling tools like ruyi_human_click, ruyi_human_drag, and ruyi_human_scroll by focusing purely on movement. Mentioning bezier/windmouse algorithms and anti-detection scenarios further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies the use case: '需要反检测场景下的鼠标操作' (mouse operations in anti-detection scenarios) and contrasts with js-reverse-mcp's lack of this capability. It gives clear context but does not explicitly mention alternatives or when not to use it among the ruyi_human_* 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?
With no annotations, the description carries the full burden. It discloses the responseStarted stage, URL pattern filtering, and the need for ruyi_intercept_wait to consume. However, it omits important behavioral details such as how to stop interception, what happens to responses if not consumed, and potential side effects on page flow. This is moderate disclosure, not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each providing distinct information: the action, the filtering capability, and the consumption mechanism. It is front-loaded with the core purpose and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that starts stateful interception, the description provides the essentials (start, filter, consume) but lacks important context like how to stop (ruyi_intercept_stop is a sibling but not mentioned), the meaning of pageIdx, and lifecycle/cleanup behaviors. Given no output schema and no annotations, this is a minimal but not fully complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description explains that URL pattern filtering is supported, adding meaning to the urlPatterns parameter beyond its schema description. However, pageIdx has no description in either schema or description, leaving its purpose unexplained. The description adds some value but does not fully compensate for the missing pageIdx semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Begin intercepting HTTP responses (responseStarted stage)' with a specific verb and resource. It also distinguishes itself from the sibling ruyi_intercept_requests by focusing on 'responses' and specifying the stage. This is a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by saying intercepted responses are consumed with ruyi_intercept_wait, indicating the workflow. It does not explicitly mention when not to use it or contrast with ruyi_intercept_requests, but the response-specific focus and the reference to ruyi_intercept_wait imply appropriate usage scenarios.
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?
The description clearly states the tool's behavior: listing all open tabs. With no annotations, the description carries the full burden, and 'list' inherently implies a read-only operation with no side effects. It is sufficient for a simple list tool, though it does not mention any additional details like sorting or formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese (translated as 'List all open tabs'). It is front-loaded with the core action and contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description does not explain what information is returned for each tab (e.g., ID, title, URL). This is a gap because an agent would need to know how to correlate list results with actions like select_page. Otherwise, the simplicity of the operation makes it mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain parameter semantics. The schema coverage is trivially 100% (empty schema). Baseline for 0 parameters is 4, and the description adds nothing beyond what is already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有打开的标签页' (List all open tabs) uses a specific verb ('列表/list') and clearly identifies the resource (open tabs/pages). It differentiates from siblings like select_page, new_page, and close_page by its listing function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as select_page or new_page. The context that it lists open tabs is implied but there are no stated use cases, prerequisites, 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?
没有 annotations,描述补充了首次调用自动启动 Firefox 这一重要行为,并列出可配置功能(代理、指纹、无头模式、隐私模式)。但未披露副作用(如 cookie 处理)、超时行为或返回内容,透明度有限。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
仅两句话,第一句直接陈述功能,第二句概括主要特性和自动启动行为,信息密度高且无冗余,符合 front-loaded 原则。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于包含 8 个属性和嵌套对象的工具,描述覆盖了核心功能与关键行为,但缺少返回值说明、container 参数的行为解释以及边界条件(如浏览器未安装)的处理。在无输出 schema 的情况下,信息还不够完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 对全部 8 个参数都有描述,覆盖率 100%。描述中提到的代理、指纹、无头等与 schema 属性对应,但没有额外补充参数的语义或使用细节,因此保持在基线水平。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明核心功能:在 ruyipage 指纹浏览器中打开新标签页并导航到目标 URL。这一定义具体且与同类工具(如 ruyi_navigate_page)区分,因为强调'新标签页'而不是简单导航。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述了主要使用场景(打开新标签页并导航)以及首次调用自动启动 Firefox 的行为,提供了清晰的上下文,但没有明确说明何时不使用或提供替代工具。
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 takes on full responsibility for disclosure. It proactively explains the mechanism (injecting debugger; statements), the limitation ('当前 BiDi 不支持完整的 CDP 式断点调试'), and that condition is not yet supported. This is transparent about key behavioral traits, though it does not detail side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two clauses stating the action and mechanism, plus a clearly flagged warning about BiDi limitations. Every sentence contributes to understanding the tool without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is reasonably detailed but leaves gaps: it does not mention what the tool returns on success/failure or how the breakpoint can be removed (although sibling tools like ruyi_remove_breakpoint exist). 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with text, condition, and urlFilter already described. The description adds no new parameter-level detail beyond confirming the text parameter's role ('代码文本、URL 片段或函数名'), which matches the schema. This is a typical case where the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '设置软断点' (set soft breakpoint) and the mechanism ('通过 preload script 注入 debugger 或 Proxy 包装'). It also specifies the scope of matching ('支持 XHR/Fetch URL 断点和函数名匹配'), distinguishing it from the sibling tool ruyi_break_on_xhr which is XHR-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it supports (XHR/Fetch URLs and function names) but does not explicitly contrast with alternatives like ruyi_break_on_xhr or provide when/when-not guidance. The BiDi limitation is a caveat, not a usage directive.
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 transparency burden. It discloses key behavioral traits: native wheel action, single direction, small steps, random intervals, and the fact that it does not locate elements or automatically scroll back. It does not, however, discuss other potential behaviors such as interaction with page end or interruption, leaving some 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, consisting of just two sentences that pack behavior, limitations, and usage. Every phrase adds value with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers the core behavior and limitations well, but it omits clarifications for parameter semantics like pageIdx and fails to mention what happens at the end of the page. Given the complexity, the description is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference any of the seven parameters, and the schema leaves pageIdx undescribed and direction without a description (though the enum is self-explanatory). With 71% schema coverage, the lack of compensation in the description leaves ambiguity for two parameters, especially pageIdx.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action: it uses Firefox's native wheel action to scroll in one direction with small steps and random intervals. It distinguishes itself from sibling human-interaction tools (move, drag, click, input) by focusing specifically on scrolling and explicitly noting it does not locate elements or auto-scroll 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states suitable scenarios ('reading-style scrolling' and 'pagination buttons gradually entering the viewport') and gives an exclusion by saying it will not locate elements or auto-roll back. However, it does not name alternative tools explicitly, so it lacks the explicit alternatives reference of the highest score.
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 full responsibility for behavioral disclosure. It states the core actions but does not mention potential side effects, error conditions (e.g., invalid pageIdx), or whether it waits for page load. This is minimal but not misleading for a navigation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and lists sub-operations efficiently. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with full schema documentation, the description covers the essential purpose and operations. It lacks explicit guidance on failure behavior, but given the tool's simplicity and the absence of an output schema, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema (100% coverage), so the description adds no extra meaning beyond what is already present. The baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool navigates an existing tab to a URL or performs refresh/forward/back. It uses a specific verb ('navigate') and resource ('existing tab'), distinguishing it from ruyi_new_page, which opens a new tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage on existing tabs, providing clear context that this is not for creating new tabs. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
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 states that fingerprint spoofing is applied to the current page and mentions the need to configure hardware fingerprint randomization at page creation, which is useful. However, it does not disclose whether the settings persist across navigations, how to reset them, or any potential side effects on page behavior. This lack of reversibility/persistence information is a notable gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the primary purpose. The first sentence states the main action, and the second adds a useful contextual note about hardware fingerprint randomization. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects), the schema carries most of the explanatory weight. The description provides a clear high-level overview and adds the limitation about hardware fingerprint randomization requiring configuration at page creation. It does not explain the interaction between this tool and sibling emulation tools, but the current page scope is stated, making it reasonably complete. A 5 would require more explicit guidance on when to use this combined tool vs. individual ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides highly detailed descriptions for all parameters (90% coverage), so the description does not need to explain them individually. The description adds a high-level summary of the parameter categories but contributes little beyond the schema. It does mention the 22-dimensional hardware fingerprint randomization, but that is not a parameter of this tool, so it adds marginal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: apply fingerprint spoofing to the current page. It enumerates the specific spoofable dimensions (geolocation, timezone, language, UserAgent, viewport, outer window, screen, CSP bypass), distinguishing it from single-purpose sibling tools. The verb 'apply' and resource 'current page' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a combined tool for setting multiple fingerprint dimensions independently, which suggests it can be used instead of individual emulation tools. However, it does not explicitly state when to prefer this over dedicated siblings like ruyi_emulate_geolocation, nor does it provide exclusions or alternative recommendations. The context is clear but the guidance is implicit rather than explicit.
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 what information is returned (alive, URL, counts), making the output behavior transparent. However, it does not explicitly state that this is a read-only, side-effect-free operation, which could be assumed from 'status' but is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that lists all key output fields without any filler. Every word is useful and the structure is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status tool with no output schema, the description fully specifies the return contents. It is complete and self-contained for an agent to understand what information will be retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms this. The description adds no parameter detail, but with no parameters to document, the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get browser current status' and enumerates the specific fields returned (alive, current URL, page count, breakpoints, preload script count). This is a specific verb+resource and distinguishes from sibling tools like list_pages or list_breakpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given its status-checking nature, it implied but not explicitly stated that it's a general health/state inspection tool without exclusions or preconditions.
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 full burden. It discloses a critical behavioral trait: only requests initiated after injection are captured, and the call stack format is Error().stack. It includes a warning, but does not mention how to reverse the injection or potential side effects, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core action and purpose, the second sentence provides essential usage context and a warning. No filler or redundant content; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that enables a specific capability (initiator tracking), the description covers the main purpose, the follow-up step, and the key limitation. It doesn't explain return values or how to stop the injection, but given the tool's narrow role and no output schema, the information provided is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter pageIdx has 0% schema description coverage, and the tool description does not explain its meaning or effect. Without any clarification, an agent cannot confidently determine what pageIdx selects or how to use it, especially since the tool likely operates on a specific page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('inject fetch/XHR Proxy') and the purpose ('capture call stacks of subsequent JS requests'). It distinguishes itself from siblings by specifically targeting initiator capture and referencing the companion tool ruyi_list_network_requests, making its role in the workflow explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: inject first, then use ruyi_list_network_requests to see initiator info. It also highlights a key limitation (only catches requests after injection). It doesn't explicitly compare to alternative interception tools, but the usage pattern is well implied.
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 disclosure burden. It reveals the internal sequence (move→hold→wait→human_move→wait→release) and the version-specific behavior of ruyiPage 1.2.54 merging press-to-release into a single performActions call, plus the flexibility of source/target as selectors or viewport coordinates. It doesn't cover failure handling or return values, but the core behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and then adding technical and usage context. Every sentence contributes value—sequence, merge behavior, and input options—with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no annotations and no output schema, the description covers the core behavior and use cases but omits important parameter semantics like style (e.g., arc vs linear) and algorithm (bezier vs windmouse). It also doesn't mention page selection or return behavior, leaving the tool underspecified for more advanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is around 70%, with several parameters (button, holdMs, releaseMs) already documented. The description adds the key insight that source/target can be either element selectors or viewport coordinates, clarifying the two representation options. However, it doesn't explain the meaning of style, algorithm, or pageIdx, leaving important parameter semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines an atomic human-like mouse drag operation with a specific sequence (move→hold→wait→human_move→wait→release), which distinguishes it from sibling tools like ruyi_human_click and ruyi_human_move. It also explicitly mentions applicable scenarios (sliders, sorting, drag-and-drop), leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is suitable for sliders, sorting, and drag-and-drop scenarios, providing clear usage context. However, it doesn't explicitly mention when not to use this tool or name alternative tools like ruyi_human_move for simpler pointer operations, so it falls short of the fullest guidance.
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?
Without annotations, the description carries the full burden. It adds useful context about the stability of contextId and the mapping mechanism via iframe.contentWindow for srcdoc or same-URL frames. However, it does not disclose potential side effects, failure modes, or whether the selection is persistent beyond the evaluate_script 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and provides essential detail without waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the primary flow and integration with evaluate_script, but with no output schema and no annotations, it omits information about return values, error cases, and whether the selection persists across multiple calls. For a relatively simple selection tool, the essentials are present but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage, so baseline is 3. The description adds value by explaining that contextId is the most stable option and that selector uses iframe.contentWindow mapping, which enriches the understanding of parameter choice. It does not mention pageIdx, but that is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: selecting a specified iframe/frame. It distinguishes from siblings by specifying that contextId comes from ruyi_list_frames and that the selected frame is used in subsequent evaluate_script calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use contextId vs selector, noting contextId is most stable. It also explains the follow-up usage with evaluate_script via frameContextId, giving a clear workflow context. It does not explicitly name alternative tools for exclusion, but the integration hint is sufficient.
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 full burden. It discloses key behavioral traits: the injection effect, the limitation to post-injection connections, the storage location (window.__ruyi_ws_messages), and the binary-frame marker. It does not explain how to stop the injection or any side effects on the page, but the disclosed information is substantial and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the main action, the second explains the effect, and the warning follows. Every sentence adds value without repetition, and the warning is highlighted appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (one optional param, no output schema), and the description covers the core behavior well—what it does, what it captures, and where messages are stored. Missing elements include parameter semantics and explicit side-effect/reversal guidance, but overall the description is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (pageIdx) with 0% coverage in the description. The description does not mention pageIdx at all, leaving the agent to infer that it selects the page. For a tool with a single optional parameter, this is a notable gap; the description should at least indicate that pageIdx designates which page to inject into.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: injecting a WebSocket proxy to capture messages from subsequent WebSocket connections. It specifies the injectable resource (WebSocket Proxy), the action (inject), and the outcome (messages recorded to window.__ruyi_ws_messages). This distinguishes it from sibling tools like ruyi_get_websocket_messages (which retrieves messages) and ruyi_capture_start (which captures network requests).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: before creating WebSocket connections, and explicitly warns that only connections created after injection are captured. However, it does not explicitly mention alternatives or when not to use it, though the sibling ruyi_get_websocket_messages implies a complementary retrieval step.
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 of behavioral disclosure. It reveals that the tool does not spawn a process, does not navigate, and preserves the external browser after MCP exit or bridge timeout—valuable context beyond the schema. It does not mention potential failure modes or side effects of takeover, but covers the most critical safe behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single dense sentence that front-loads the main action (takeover via port) and then adds behavioral exclusions and retention semantics. Every clause earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an attach tool with 4 parameters, the description covers the core use case, prerequisites (external Firefox with BiDi port), non-actions (no new process/no navigation), and post-exit retention. Without an output schema, no return-value explanation is required. Minor missing details like error behaviors or how the browser is selected beyond the port, but schema fills most structured gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters (port, address, profilePath, traceEnabled), each with clear descriptions. The tool description adds no extra parameter semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: '接管已启动的浏览器' (take over an already-started browser) via the Firefox WebDriver BiDi port. It clearly distinguishes from siblings by explicitly stating it does not create a new process or navigate pages, which differentiates it from ruyi_new_page, ruyi_navigate_page, and ruyi_browser_quit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when an external Firefox browser is already running with a remote debugging port. It also explains a key benefit (browser persists after MCP exit or bridge timeout), which guides selection for persistent external browser control. It lacks an explicit comparison to alternatives, but the 'does not create a new process' exclusion provides clear when-not 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 carries the full burden. It discloses two meaningful behaviors: default returns full request/response bodies, and internally drains via single-packet RPC to avoid overwhelming the bridge. However, it does not describe error handling or timeout behavior beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 covers the essential context: what it does, when to use it, what to expect (full bodies), and a performance rationale. It does not explain return structure in detail, but for a retrieval-after-start tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params described). The description adds some context by explaining that full bodies are returned by default, which aligns with maxBodyChars=0, and the internal drain mechanism hints at count/pageIdx behavior. However, pageIdx remains undocumented in both schema and description, so 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '等待并获取抓包结果' (wait and get capture results), specifying the exact verb and resource. It also mentions it should be used after ruyi_capture_start, which distinguishes it from capture start/stop and intercept wait siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: '在调用 ruyi_capture_start 后使用' (use after calling ruyi_capture_start). This provides clear context and sequencing, though it does not explicitly mention alternatives 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 carries the full burden. It adds useful behavioral constraints: function must return a JSON-safe value and supports accepting a local file as a parameter. However, it does not disclose potential side effects or security implications of arbitrary JavaScript execution, nor error/timeout behavior, which are relevant for an eval 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, front-loaded with the primary action and result. Each sentence contributes new information: purpose, use cases, return constraint, and file support. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations or output schema, the description is reasonably complete. It covers the core action, acceptable return values, and input flexibility. It could be more complete by addressing error behavior or side-effect warnings, but the provided details are sufficient for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 4 parameters (100% coverage), so the baseline is 3. The description adds value beyond the schema by emphasizing that the function must return a JSON-safe value and that a local file can be passed as a parameter, which are non-obvious constraints not fully captured in the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: '在浏览器页面中执行 JavaScript 函数并返回结果' (execute JavaScript function in browser page and return result). It also lists concrete use cases (runtime sampling, Hook injection, reading page state) that distinguish it from sibling script-management or DOM tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: '可用于运行时采样、Hook 注入、读取页面状态', giving clear context for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
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?
The description mentions it is based on the performance API, implying a read-only, non-intrusive operation, but does not explicitly disclose non-destructive behavior or limitations (e.g., no request bodies or timing details). With no annotations, more behavioral context could be expected, but this adds some 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose, followed by a clear alternative. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with no required parameters. The description clarifies the data source (performance API) and directs users to a more detailed alternative. While it does not explain pagination or return format, the output schema absence makes some additional info helpful, but the essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers limit and urlFilter with descriptions (67% coverage), and the description does not add extra meaning for parameters. pageIdx lacks description, and this description does not compensate, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '列出最近的网络请求' (list recent network requests) with a specific verb and resource. It also distinguishes itself from alternatives by suggesting ruyi_capture_start for more detailed information, aligning with the sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use this tool for basic resource loading info and when to use ruyi_capture_start instead ('需要更详细信息时'). This provides clear usage context and an alternative, fulfilling the when/when-not 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 carries the full burden. It discloses a key behavioral trait: it clears unconsumed queue/history, which is a potentially destructive action, and explains why. However, it doesn't mention how pageIdx affects scope or whether the operation is reversible, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose. Each sentence serves a distinct function: stating the action and providing a critical prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 covers the core action and a critical prerequisite (call wait first). It does not cover parameter semantics or return behavior, but these are secondary. The description is adequate for an agent to use the tool correctly in most cases, though a mention of pageIdx would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only cleanupTimeout has a description). The description adds no information about either parameter. pageIdx is completely undocumented in both schema and description, and its meaning is not obvious from context. The description should have explained that pageIdx selects the page/context to stop.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '停止被动抓包' (stop passive capture) with a specific verb and resource. It also distinguishes from related tools by mentioning the side effect of clearing unconsumed queue/history and the need to call ruyi_capture_wait first, which differentiates it from a simple stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: if results are needed, call ruyi_capture_wait first before stopping. It also explains the rationale (avoiding implicit body read), providing clear guidance on the proper sequence of calls. This is strong usage direction.
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 key behavioral trait of character-by-character input with delay and its anti-detection intent. It does not detail side effects or limitations, but the core behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and key behavioral detail. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple input simulation tool, the description fully covers the core purpose and behavior. Given the schema provides parameter details and there is no output schema, the description is complete enough to guide selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, which is high, so the baseline is 3. The description does not add meaning beyond the schema; it only mentions 'text' and 'delay' implicitly. The pageIdx parameter remains undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates human typing character-by-character with delay, which is a specific verb and resource. It also distinguishes from sibling tools like ruyi_dom_input by emphasizing the anti-detection aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when avoiding detection as automated input is important, which provides clear context. However, it does not explicitly name alternatives or state when not to use it, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details buffer clearing on first call, preservation on repeated calls, omission of pre-launch events, and the true enabling of recording even after browser launch. This is rich behavioral context beyond what annotations could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but every sentence adds necessary nuance about buffer behavior, startup coverage, and protocol scope. It is front-loaded with the core action and structured logically, earning its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of trace-start behavior and no annotations, the description covers key behavioral aspects and mentions the startup alternative. However, it does not explicitly connect to ruyi_trace_stop or mention return values, leaving a minor gap in complete contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning for the two parameters. Schema coverage is 50% (only outputFile has a description), and the description does not compensate for the undocumented pageIdx. Although pageIdx may be inferable from context, the description itself provides no parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts recording a structured BiDi trace from the current moment, using a specific verb and resource. It also distinguishes itself from other tools (e.g., ruyi_trace_stop, ruyi_trace_get_results) and from Firefox's DOMTrace, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when buffer is cleared vs. preserved, and when repeated calls occur. It directly names an alternative (use ruyi_new_page with traceEnabled:true) to capture startup events, fulfilling the 'when to use vs alternatives' criterion.
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?
No annotations are present, so the description carries the full burden. It discloses a critical behavioral nuance: for port-takeover external browsers, it only disconnects and does not close the process. This goes beyond the tool name's implication and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a semicolon that separates two scenarios. It is front-loaded with the main action and provides the exception in a compact format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description covers all essential information: what happens in both MCP-started and external-browser cases. It is complete for an agent to know exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is empty. The baseline for 0 parameters is 4, and the description adds useful behavioral context about the two operation modes, which compensates for the lack of parameter-related details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: closing a browser started by MCP and cleaning state. It also distinguishes the behavior for externally attached browsers (disconnect only), which differentiates it from sibling tools like ruyi_close_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (when needing to quit the browser) and explicitly contrasts behavior based on how the browser was started. It does not explicitly mention alternatives, but the distinction between MCP-started and external browsers serves as practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It states that the proxy cannot be switched after browser startup, that this tool does not actually switch proxies, and that it only returns status information. It also clarifies that the proxyUrl parameter is for reference only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each packed with essential information. It front-loads the critical warning about proxy setup, states the tool's limitation, and gives the correct procedure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and no annotations, the description is complete. It explains the tool's purpose, its limitation, the correct usage pattern, and what it returns (instructions and current proxy status). There are no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for proxyUrl already states it is '仅参考，不会实际切换' (reference only, no actual switch), and the tool description reinforces this. The added context about the tool's non-functional nature and the correct alternative workflow enhances the parameter's meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool '仅返回说明和当前代理状态' (only returns instructions and current proxy status), which clearly defines its purpose despite the misleading name. It also distinguishes itself from ruyi_new_page by explaining that the proxy must be set there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions on when to use this tool: not for switching proxy but for checking status. It provides the correct alternative workflow: quit browser with ruyi_browser_quit, then call ruyi_new_page with the new proxy. This is clear and actionable.
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:

[![ruyi-mcp MCP server](https://glama.ai/mcp/servers/Facetomyself/ruyi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Facetomyself/ruyi-mcp)

Score Badge

Copy to your README.md:

[![ruyi-mcp MCP server](https://glama.ai/mcp/servers/Facetomyself/ruyi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Facetomyself/ruyi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Facetomyself/ruyi-mcp'

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