Server Quality Checklist

Tool Scores

• get_network_requestsA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying 'latest', 'vConsole', and 'connected mobile H5 page', but it does not disclose output shape, ordering, or how filters behave. This is acceptable given annotations, but some behavioral detail is still left implicit.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or redundant wording. It front-loads the action and the resource, making the tool's purpose immediately clear. Every part of the 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?

  With 5 optional parameters and no output schema, the description is somewhat thin: it omits what each request record contains, how pagination works, and how filters like failedOnly or urlIncludes operate. However, the parameters are fairly self-explanatory and the annotations cover the safety profile, making the description minimally adequate for a read-only tool. More return-format detail 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?

  The input schema has 0% description coverage, and the description does not explain the parameters limit, pageId, failedOnly, includeBody, or urlIncludes. The word 'latest' gives some meaning to limit, and the mobile page context partially clarifies pageId, but most parameter semantics are left to the agent to infer from names alone. The description does not adequately compensate for the schema gap.

  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?

  States a specific action ('Read') and resource ('latest network requests captured by vConsole on a connected mobile H5 page'). This clearly distinguishes it from sibling tools like list_pages, get_console_logs, and execute_javascript. The source and scope are precise enough for an agent to recognize 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 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 network request data from vConsole is needed, but it does not explicitly state when to use it over get_console_logs or other alternatives. No when-not or exclusion guidance is provided. The intended use case is inferable rather than explicit.

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

• get_console_logsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds minor context by saying 'latest' and specifying the vConsole source, but does not disclose behavior like buffer limits, return format, or whether logs require the page to have vConsole enabled.

  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 with no filler. Every word contributes to conveying the tool's purpose and context.

  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 read-only tool with strong annotations, this is minimally viable. However, the absence of an output schema and the complete lack of parameter guidance means the agent is left to infer return shape and the roles of pageId/pluginId. The description is functional but bare.

  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 0%, so the description should compensate for the four parameters, but it does not mention level, limit, pageId, or pluginId at all. The parameter names and schema constraints provide some self-explanatory meaning, but the description adds zero value for 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 uses a specific verb ('Read'), identifies the exact resource ('console logs captured by vConsole on a connected mobile H5 page'), and clearly distinguishes itself from sibling tools like get_network_requests and execute_javascript. The purpose is immediately understandable.

  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 about when this tool is relevant: reading console logs captured by vConsole on a connected mobile H5 page. It does not explicitly mention alternatives or exclusions, but the sibling tool names make the differentiation obvious.

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

• execute_javascriptA
  4/5.0
  Behavior5/5

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

  The description goes beyond the annotations by specifying concrete consequences: arbitrary code may mutate page state or storage, expose sensitive data, and send network requests. This complements the destructiveHint and openWorldHint flags and warns the agent about the non-read-only, potentially harmful nature of the operation. There is no contradiction with the 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 only two sentences long and both sentences carry essential information: the core action and the risk profile. It is front-loaded and free of fluff, making it easy for an agent to parse quickly.

  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 covers the authorization requirement and the main risks, but there is no output schema and the description does not state what the tool returns, how errors are reported, or how pageId relates to list_pages. For a high-complexity, high-risk tool, this leaves some important gaps for an agent trying to invoke it 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 0%, and the description does not explain any of the parameters (pageId, code, timeout). The parameter names are somewhat self-explanatory, but the description adds no guidance on how to obtain pageId, how code will be executed, or what timeout controls. This is a meaningful gap given the lack of schema 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 states a specific action and target: 'Execute JavaScript in a connected mobile H5 page later explicit authorization in vConsole.' This clearly differentiates it from sibling tools like list_pages, get_console_logs, and get_network_requests, which are read-only inspection tools rather than code-execution tools.

  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 gives one important precondition: explicit authorization in vConsole. However, it does not explicitly say when to prefer this tool over the sibling read-only tools, nor does it state when not to use it. The usage context is implied by the contrast with the sibling tools but not spelled out.

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

• list_pagesA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the useful context that the result reflects pages 'currently connected through vConsole,' indicating a live snapshot, but it does not disclose return shape, ordering, or pagination.

  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 no filler. The verb and object are front-loaded, and every word contributes to understanding the tool's purpose.

  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, read-only listing tool with annotations covering safety and no output schema, the description is sufficient for an agent to select and invoke it correctly. No additional operational details are necessary.

  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 there is no parameter detail for the description to add. Per the baseline for parameterless tools, a 4 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 states a specific verb ('List') and resource ('mobile H5 pages currently connected through vConsole'), making the tool's purpose unmistakable. It is also clearly distinct from sibling tools that handle console logs, network requests, and JavaScript execution.

  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 when to use the tool — when you need the currently connected mobile H5 pages — but it does not explicitly mention alternatives or exclusions. Sibling tool names suggest differentiation, but the description itself leaves that inference to the agent.

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