Server Quality Checklist

Tool Scores

• scrappey_browser_actionC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions supported actions but lacks critical behavioral details: it doesn't specify error handling (e.g., what happens if an action fails), performance characteristics (e.g., timeouts, rate limits), authentication needs, or side effects (e.g., whether actions are reversible). The list of actions is informative but insufficient for a tool with 32 parameters and complex automation capabilities.

  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 and front-loaded: a single sentence that states the core purpose and enumerates key actions. Every word earns its place by conveying essential information without redundancy or fluff, making it efficient for quick comprehension.

  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's high complexity (32 parameters, no annotations, no output schema), the description is inadequate. It lacks information on output format, error responses, session dependencies, and behavioral constraints. For a powerful automation tool with many configuration options, the description should provide more context about how actions are executed, what results to expect, and common pitfalls.

  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%, so the schema already documents all 32 parameters thoroughly. The description adds minimal value beyond the schema by listing action types (e.g., 'clicking, typing, scrolling') but doesn't explain parameter interactions, defaults, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

  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 purpose: 'Execute browser automation actions in a session' with a list of supported actions (clicking, typing, etc.). It specifies the verb ('execute') and resource ('browser automation actions'), but doesn't explicitly differentiate from sibling tools like scrappey_request or scrappey_screenshot, which might have overlapping functionality.

  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 doesn't mention prerequisites (e.g., needing a session from scrappey_create_session), exclusions, or comparisons to sibling tools like scrappey_request (for simpler requests) or scrappey_screenshot (for just screenshots). Usage is implied by the action list but not explicitly defined.

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

• scrappey_requestC
  2.9/5.0
  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. While it mentions 'antibot bypass capabilities,' it fails to describe critical behavioral traits: whether this is a read-only or destructive operation, authentication requirements, rate limits, error handling, or what the response format looks like. For a complex tool with 41 parameters, this is a significant gap in 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 extremely concise and front-loaded: a single sentence that captures the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. This is an excellent example of efficient communication for a tool with extensive schema documentation.

  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's high complexity (41 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't address what the tool returns, error conditions, performance characteristics, or how it integrates with sibling tools. While the schema covers parameters well, the description fails to provide the broader context needed for effective tool 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 description coverage is 100%, so the schema already documents all 41 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter relationships, default behaviors, or practical examples. The baseline score of 3 reflects adequate coverage through the schema alone, with no extra value from the 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 purpose: 'Send an HTTP request using Scrappey with antibot bypass capabilities. Supports GET, POST, PUT, DELETE, PATCH methods.' This specifies the verb ('Send an HTTP request'), resource ('using Scrappey'), and key capability ('antibot bypass'). However, it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' or 'scrappey_create_session', which likely have overlapping web interaction functionality.

  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 mentions 'antibot bypass capabilities' but doesn't explain when this is needed compared to simpler HTTP requests or other sibling tools. There are no usage prerequisites, exclusions, or named alternatives provided, leaving the agent with minimal contextual direction.

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

• scrappey_screenshotC
  2.9/5.0
  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 optional browser actions capability but doesn't describe important behaviors: whether this is a read-only operation (likely, but not stated), what happens with sessions, rate limits, authentication needs, error handling, or what the output looks like (image format, size). The description is minimal for a tool with 15 parameters and complex functionality.

  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 perfectly concise with two sentences that each add value. First sentence states core functionality, second adds the key optional capability. No wasted words, front-loaded with the main purpose.

  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 complex tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (image data format? file? URL?), doesn't mention performance characteristics, error conditions, or practical constraints. The agent would need to infer too much from the parameter schema alone.

  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%, so the schema already documents all 15 parameters thoroughly. The description adds no parameter-specific information beyond implying that 'browserActions' can be used before capturing. It doesn't explain parameter relationships, default behaviors, or practical usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 purpose: 'Take a screenshot of a webpage' (specific verb+resource). It adds 'Optionally execute browser actions before capturing' which distinguishes it from basic screenshot tools, though it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' which might handle browser actions separately.

  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 doesn't mention sibling tools like 'scrappey_browser_action' (for actions without screenshot), 'scrappey_request' (for non-browser requests), or 'scrappey_create_session' (for session management). There's no context about prerequisites or typical use cases.

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

• scrappey_session_activeC
  2.9/5.0
  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 the tool checks session activity but doesn't describe what 'active' means (e.g., browser session status, timeout behavior), response format (e.g., boolean, status details), error handling, or any rate limits. This leaves significant gaps for a tool that likely interacts with 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 a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple check operation, 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.

  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 and output schema, the description is incomplete. It doesn't explain what 'active' entails, the return value (e.g., true/false, status object), or error cases (e.g., invalid session ID). For a session management tool with no structured output, more context is needed to guide the agent effectively.

  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 doesn't add any parameter semantics beyond what the input schema provides. The schema has 100% description coverage, clearly documenting the single required 'session' parameter as a session ID to check. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 purpose as checking if a specific session is active, using the verb 'check' and specifying the resource 'session'. It distinguishes from siblings like 'scrappey_list_sessions' (which lists sessions) and 'scrappey_destroy_session' (which destroys sessions), but doesn't explicitly differentiate from all siblings like 'scrappey_browser_action' or 'scrappey_request'.

  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 doesn't mention prerequisites (e.g., needing a valid session ID), exclusions, or relationships with sibling tools like 'scrappey_list_sessions' (which might be used to get session IDs first). Usage context is implied but not explicit.

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

• scrappey_create_sessionB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that sessions 'persist browser state across requests,' which hints at statefulness, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what happens on failure. For a creation tool with zero annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose and followed by a clarifying detail about session persistence. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and easy to parse.

  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 complexity of creating a browser session with multiple configuration options (8 parameters) and no annotations or output schema, the description is incomplete. It lacks information on return values, error conditions, or how the session integrates with other tools, leaving significant gaps for the agent to operate effectively.

  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%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps because there are none 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 specific action ('Create a new browser session') and resource ('in Scrappey'), with additional context about what sessions persist ('browser state like cookies, localStorage across requests'). It distinguishes from siblings like 'scrappey_destroy_session' and 'scrappey_list_sessions' by focusing on creation rather than management or listing.

  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 doesn't mention prerequisites, when to choose this over other session-related tools, or any specific scenarios where creating a session is necessary versus using direct requests. This leaves the agent without context for tool selection.

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

• scrappey_list_sessionsB
  3.2/5.0
  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 states it lists active sessions but doesn't mention what 'active' means, whether it's read-only or has side effects, or any rate limits or authentication requirements. This leaves significant gaps for an agent to understand the tool's 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?

  The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without redundancy or fluff.

  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 0 parameters and no output schema, the description is minimally adequate by stating what it does. However, with no annotations and sibling tools present, it lacks details on behavior, usage context, and output format, making it incomplete for optimal agent understanding.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and a baseline of 4 is applied since it doesn't add unnecessary information beyond what the schema provides.

  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 ('List all') and target resource ('active sessions for the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'scrappey_session_active' which might serve a similar purpose, preventing a perfect score.

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

  Usage Guidelines2/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 like 'scrappey_session_active' or 'scrappey_destroy_session'. It lacks context about prerequisites, such as whether authentication is required, or any explicit when-not-to-use scenarios.

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

• scrappey_destroy_sessionB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It discloses that the tool destroys a session to free resources, indicating a destructive action, but doesn't mention behavioral traits like whether destruction is irreversible, what happens to associated data, error conditions, or rate limits. For a destructive tool with zero annotation coverage, this leaves significant gaps in understanding the operation's impact.

  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 directly states the tool's purpose and benefit ('to free resources'). It is front-loaded with the core action and avoids unnecessary details, making it highly concise and well-structured for quick understanding.

  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's complexity (destructive action with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but doesn't address return values, error handling, or resource implications. For a destructive tool, more context on outcomes or safety would improve completeness, but it meets a baseline level.

  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%, with the single parameter 'session' documented as 'Session ID to destroy.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately defines the parameter without extra description needed.

  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 ('Destroy') and resource ('existing browser session in Scrappey'), making the purpose unambiguous. It distinguishes from siblings like 'scrappey_create_session' and 'scrappey_list_sessions' by focusing on termination rather than creation or listing. However, it doesn't explicitly contrast with 'scrappey_session_active' which might check session status.

  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 needing to 'free resources,' suggesting it's for cleanup after session use. However, it doesn't specify when to use this tool versus alternatives (e.g., whether to destroy vs. keep sessions active for reuse) or provide explicit exclusions. The context is clear but lacks detailed guidance on timing or prerequisites.

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