Server Quality Checklist

Tool Scores

• webextrator_get_tasks_batchA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries burden. Mentions returns JSON with statuses and result data, but no details on idempotency, rate limits, or side effects. Adequate but not detailed.

  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 paragraphs, front-loaded with purpose and usage guidelines. 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 output schema exists and good parameter documentation, description is mostly complete. Could mention that tasks are created by webextrator_extract or webextrator_render, but not essential.

  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% with parameter descriptions. Description adds context on pagination and batch retrieval by IDs/trace_ids, but does not significantly enhance understanding 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?

  Clearly states it retrieves results of multiple extract/render tasks, distinguishing from sibling webextrator_get_task which handles single task retrieval.

  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 describes when to use: after multiple async requests or for pagination. Lacks explicit 'when not to use' but context is clear.

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

• webextrator_extractA
  4.2/5.0
  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 clearly explains the navigation/rendering/extraction flow, default synchronous return, async behavior with task_id polling, and LLM-enhanced normalization. It does not mention caching or error scenarios, but provides substantial behavioral context beyond a bare 'extracts content'.

  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, front-loaded with purpose, and uses bullet points for usage guidance. Each sentence contributes meaningful information—purpose, when-to-use, return behavior—without 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?

  The description explains the primary use cases, return types, async workflow, and how to interact with sibling tools. While it does not cover every parameter's effect on behavior, the schema fills those gaps, and the description gives a solid mental model for this complex extraction tool.

  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 descriptions cover 100% of the 15 parameters with detailed explanations including defaults and enums. The tool description adds little parameter-level detail beyond reiterating mode='async' behavior, which the schema already covers. Since schema coverage is complete, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with the specific verb 'Extract' and resource 'structured content from a web page', clearly distinguishing this from sibling tools like webextrator_render. It also enumerates the types of data extracted (product, article, general), reinforcing 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 Guidelines4/5

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

  The description gives an explicit 'Use this when' list covering structured extraction needs, and even points to the correct sibling (webextrator_get_task) for polling async tasks. However, it does not explicitly state when NOT to use it (e.g., when rendering without extraction is needed), so it stops 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.

• webextrator_get_taskA
  4.2/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 burden. It states the tool returns task status and result data, and implies polling behavior. However, it does not disclose whether the task is deleted after retrieval or any other side effects. The description is adequate but not thorough.

  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 short sentences plus bullet-like use cases. It is front-loaded with the verb and resource. 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 is simple, schema covers all parameters, and output schema exists (so return format is explained). The description is sufficient for basic usage. It could mention that no parameters are required, but that is implied by default values.

  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 100% with both parameters described. The description adds value by clarifying that task_id is obtained from an extract/render request and that trace_id is an alternative lookup. This enhances understanding 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 it retrieves the result of a single previously created extract or render task. The verb 'Retrieve' and resource 'result of a single... task' are specific. It distinguishes from siblings like webextrator_get_tasks_batch which retrieves batch results.

  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 two explicit 'Use this when' conditions: after submitting an extract/render request and getting a task_id, and when wanting to poll for a specific task by ID. This gives clear context, though it could explicitly mention alternatives like 'for batch retrieval, use webextrator_get_tasks_batch'.

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

• webextrator_get_usage_guideA
  4.2/5.0
  Behavior4/5

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

  No annotations provided, but description clearly indicates a read-only operation returning a guide, with no destructive or complex side effects mentioned. Minimal but sufficient.

  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?

  Concise at 4 lines, but slightly redundant (returns statement repeats purpose). Efficient overall.

  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 help tool with no parameters and an output schema, the description is complete—states purpose and return value adequately.

  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?

  No parameters exist, so schema coverage is 100%. Description doesn't need to add param details, but could mention no parameters are required.

  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 returns a comprehensive guide for using WebExtrator tools, distinguishing it from sibling tools that perform extractions or task management.

  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?

  Implied use when guidance is needed, but no explicit when-to-use or alternatives guidance. Sibling tools are different operations, but the description doesn't advise against using them.

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

• webextrator_renderA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description bears full responsibility for disclosure. It reveals key behaviors: uses a headless browser, waits for JavaScript execution, and returns rendered HTML. It also transparently describes the async flow (returns task_id, poll until finished_at, read response). It does not cover side effects like network requests, SSRF risks, or failure modes, but what it discloses is accurate and useful.

  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 tight and well-organized: an opening action sentence, a 'Use this when' bulleted list, and a Returns section. No filler or redundant phrases. It front-loads the core purpose and only then adds usage guidance and output details, all in under 120 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 is complex with 13 parameters, async behavior, caching, and multiple options, yet the description covers the essential workflow well. It explains the sync/async difference, the return types, and typical use cases. It does not mention caching or resource blocking, but these are fully documented in the schema and an output schema exists, so the description is sufficiently complete for selection and initial 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 has 100% description coverage, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the 'mode' parameter's impact (async returns a JSON envelope with task_id), and by clarifying how to consume the output. The 'Returns:' section is a valuable addition that ties parameters to expected results.

  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 a specific verb and resource: 'Render a web page and return the fully rendered HTML.' It clearly states the tool's function and effectively distinguishes from siblings like webextrator_extract and webextrator_get_task by mentioning dynamic content, DOM inspection, and SPA capture. This is a textbook example of purpose clarity.

  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 includes an explicit 'Use this when:' section listing three concrete scenarios, which provides clear context for when the tool is appropriate. It also explains the async mode and directs users to poll with webextrator_get_task. However, it does not explicitly state when *not* to use the tool or name alternative tools as substitutes, so it misses the full 'when-not/alternatives' bar.

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