Server Quality Checklist

Tool Scores

• run_seo_auditB
  3.1/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 the tool returns a crawl ID and output path, which adds some context, but fails to cover critical aspects such as whether this is a long-running operation, potential rate limits, authentication needs, or what 'comprehensive SEO data' entails. The use of 'Crawlee HttpCrawler' hints at technical implementation but doesn't clarify behavioral traits for the agent.

  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 front-loaded and concise, consisting of two sentences that efficiently convey the core functionality and return values without unnecessary details. Every sentence earns its place by stating the action and output, 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?

  Given the complexity of a crawling tool with 4 parameters and no output schema, the description is moderately complete. It specifies the action and return values but lacks details on output format, error handling, or operational constraints. Without annotations, it should do more to guide the agent on usage and behavior, but it meets a minimum viable level for understanding the tool's basic function.

  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 fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or providing usage examples. The baseline score of 3 reflects adequate coverage by the schema alone.

  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 ('Crawl a website and extract comprehensive SEO data') and resource ('website'), specifying the tool's purpose. It distinguishes from siblings by mentioning the crawling aspect, though it doesn't explicitly contrast with tools like 'analyze_seo' or 'list_seo_queries'.

  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 'analyze_seo' or 'list_seo_queries'. The description implies usage for crawling and extracting SEO data but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.

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

• list_seo_queriesB
  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 describes a read-only listing operation but doesn't mention critical behaviors such as whether results are paginated, if there are rate limits, authentication requirements, or what the output format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

  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 efficiently structured in two sentences: the first states the core purpose and included data, the second adds optional filtering. Every word contributes to understanding, with no redundant or vague language, making it appropriately sized and front-loaded.

  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 the return values (e.g., format of 'descriptions, priorities, and fix recommendations'), potential limitations, or error handling. For a tool that lists data with multiple attributes, more context is needed to use it 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%, with both parameters well-documented in the schema (including enums and descriptions). The description adds marginal value by mentioning filtering options but doesn't provide additional semantic context beyond what the schema already states. This meets the baseline for high schema coverage.

  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: 'List all available SEO analysis queries with descriptions, priorities, and fix recommendations.' It specifies the verb ('List') and resource ('SEO analysis queries') with details about what information is included. However, it doesn't explicitly differentiate this from sibling tools like 'query_seo_data' or 'analyze_seo', which prevents 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 Guidelines3/5

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

  The description provides implied usage guidance by mentioning optional filtering by category or priority level, suggesting when to use these parameters. However, it lacks explicit guidance on when to choose this tool over alternatives like 'analyze_seo' or 'run_seo_audit', and doesn't specify prerequisites or exclusions, leaving room for ambiguity.

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

• analyze_seoB
  3.4/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 tool 'runs 25+ SQL queries' and returns a 'structured report', which gives some insight into computational intensity and output format. However, it lacks critical details like execution time, resource requirements, error handling, or whether it modifies data (though 'analyze' suggests read-only).

  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 appropriately sized with two sentences that efficiently convey core functionality. It's front-loaded with the main purpose, though the second sentence could be slightly more streamlined. Every phrase adds value 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?

  For a tool with 4 parameters, 100% schema coverage, and no output schema, the description provides adequate context about what the tool does and returns. However, it lacks details about the report structure, error conditions, or performance characteristics that would help an agent use it effectively, especially given the computational intensity implied by '25+ SQL queries'.

  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%, providing good documentation for all parameters. The description adds marginal value by mentioning 'critical issues, content problems, technical SEO issues, security vulnerabilities, and optimization opportunities', which loosely maps to the 'includeCategories' enum values. However, it doesn't explain parameter interactions or provide usage examples beyond what the schema offers.

  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 with specific verbs ('analyze SEO data', 'detect issues', 'returns structured report') and resources ('completed crawl', '25+ SQL queries'). It distinguishes from siblings by focusing on post-crawl analysis rather than listing queries, querying data, or running audits.

  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 context ('from a completed crawl') but doesn't explicitly state when to use this tool versus alternatives like 'run_seo_audit' or 'query_seo_data'. No exclusions or prerequisites are mentioned, leaving the agent to infer appropriate usage scenarios.

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

• query_seo_dataA
  3.7/5.0
  Behavior3/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 that the tool 'Returns detailed results with affected URLs and context', which gives some behavioral insight about output format. However, it doesn't mention important traits like whether this is a read-only operation, potential performance/rate limits, authentication needs, or what 'execute' entails computationally. The description adds basic context but 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.

  Conciseness5/5

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

  The description is perfectly concise with three sentences that each earn their place: first states the core purpose, second provides prerequisite guidance, third describes return format. No wasted words, front-loaded with the main action. Excellent structure for quick comprehension.

  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 3 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers purpose, prerequisite, and return format at a high level, but doesn't address behavioral aspects like safety, performance, or error handling. For a query execution tool with no output schema, more detail about result structure would be helpful.

  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 parameters thoroughly. The description adds minimal value beyond the schema: it reinforces that 'query' should be a name and mentions list_seo_queries for discovery (which is also in the schema). It doesn't provide additional semantic context about how parameters interact or usage patterns. 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: 'Execute a specific SEO analysis query by name' with the resource being 'SEO analysis query'. It distinguishes from siblings by mentioning list_seo_queries for discovery, but doesn't explicitly differentiate from analyze_seo or run_seo_audit. The verb 'execute' is specific, though not as precise as it could be regarding what execution entails.

  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 for when to use this tool: 'Use list_seo_queries to see available queries' establishes a prerequisite. It implies usage for executing named queries rather than other SEO operations, but doesn't explicitly state when NOT to use it or name alternatives among siblings like analyze_seo or run_seo_audit, which could cause confusion.

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