Server Quality Checklist

Tool Scores

• cloak_get_htmlA
  3.6/5.0
  Behavior2/5

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

  No annotations provided. Description does not disclose behavioral traits such as mutability, authentication needs, rate limits, or side effects. It only mentions anti-detection parameters by reference, leaving the agent to infer behavior from 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?

  Description is short and front-loaded with the core purpose. Every sentence adds value, referencing another tool for boilerplate parameters to avoid duplication. No unnecessary 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?

  Despite having an output schema, the description does not explain return values beyond 'HTML source code' or 'outerHTML'. The 11 parameters not described here are left to cross-reference, making this tool's description insufficient for an agent to use all features correctly without external knowledge.

  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?

  Description explains the effect of 'url' and 'selector' parameters (return full page vs. outerHTML). However, with 0% schema coverage and 13 parameters, only the first two are described; the remaining 11 are merely cross-referenced to another tool, which adds incompleteness.

  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 it opens a URL and returns rendered HTML source code, with option to select a specific element via CSS selector. This distinguishes it from siblings (cloak_get_text for text, cloak_interact for interaction, cloak_screenshot for screenshots).

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

  Usage Guidelines4/5

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

  Description implies use for structured parsing and link extraction, and mentions that anti-detection parameters are same as cloak_get_text, giving context. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

• cloak_screenshotA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full behavioral burden. It mentions the return value and that anti-detection parameters are similar to cloak_get_text, but does not disclose any side effects, whether it is read-only, or behavior on error. Adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is very concise: three sentences clearly front-loading the main purpose and then providing key usage tips. 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?

  The tool has 14 parameters but only 2 are required. Description covers the main behavior, return value, and the most critical parameters. However, many parameters (wait, timeout, humanize, etc.) rely on cross-reference to sibling tool. Given the output schema exists, completeness is good 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?

  Schema description coverage is 0%, so description must add meaning. It explains 'full_page' and 'selector' fully, and states path must be absolute. Other parameters are grouped under 'anti-detection parameters same as cloak_get_text', which is helpful but not detailed. Baseline 3 is appropriate given the cross-reference.

  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 verb (open URL, screenshot, save as PNG) and the resource (URL, path), and specifies the return value (actual file path). It effectively distinguishes from siblings like cloak_get_html and cloak_get_text which retrieve content rather than screenshots.

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

  Usage Guidelines4/5

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

  The description explains when to use full_page vs selector, and requires absolute paths for the path parameter. It also references cloak_get_text for anti-detection parameters, providing context. However, it does not explicitly state when not to use this tool or alternatives.

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

• cloak_interactA
  4.3/5.0
  Behavior4/5

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

  Details action types, extraction modes, anti-detection parameters, and humanization. No annotations exist, so description carries burden. Missing some edge-case behavior like error handling or session lifecycle, but generally thorough.

  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?

  Well-structured with bullet-pointed action types. A bit lengthy but every part adds value. No redundant information.

  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 12 parameters and complexity, description covers core functionality. References sibling for anti-detection details. Has output schema so return values not needed. Minor gaps like missing timeout_ms details.

  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 coverage is 0%, but description explains actions format, extract, selector, screenshot_path, humanize, headless, proxy, etc. Timeout_ms and max_chars are not explained, but overall adds significant meaning beyond 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 it executes a sequence of browser actions and extracts results. It differentiates from sibling tools which are for direct extraction, establishing a distinct 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?

  Provides guidance such as 'first action is usually goto' and suggests humanize=True for forms. However, lacks explicit when-to-use vs when-not-to-use compared to siblings.

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

• cloak_get_textA
  4.4/5.0
  Behavior4/5

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

  The description discloses key behaviors: uses Chromium, executes JavaScript, returns visible plain text, handles SPA/dynamic content, and includes anti-detection settings. With no annotations provided, it carries the full burden and does so adequately, though it lacks details on error handling or session management.

  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: a short paragraph for purpose and behavior, followed by a bullet list of parameters. It is front-loaded and contains no unnecessary words. Every sentence 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?

  Given the tool has an output schema (so return values are covered) and 13 parameters with no schema descriptions, the description covers the essential context: purpose, usage hints, parameter explanations, and anti-detection settings. It lacks error handling details but is otherwise complete for practical use.

  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 explains 12 of 13 parameters with meaningful context (e.g., selector limits to CSS selector, max_chars truncates). It does not describe timeout_ms, missing from the bullet list. The explanations add value beyond the schema, which has 0% description 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 opens a URL with an invisible Chromium browser and returns visible plain text, suitable for LLM analysis. It distinguishes itself from sibling tools (cloak_get_html, cloak_interact, cloak_screenshot) by focusing on plain text extraction with JavaScript execution for dynamic content.

  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 specific guidance for bypassing Cloudflare/reCAPTCHA by setting proxy, geoip, humanize, and headless. It implies the tool is for text extraction from dynamic pages but does not explicitly compare with siblings for when to use alternatives. The context 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.