Server Quality Checklist

Tool Scores

• sagrank_auditB
  3.3/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 responsibility for disclosing side effects, permissions, or destructive actions. It only describes the audit as a calculation and reporting activity, but does not explicitly state whether it is read-only, whether it makes network requests, or if there are any rate limits or costs. There is no contradiction, but transparency is lacking.

  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 a single, moderately long sentence that packs a lot of information. It is clear and free of fluff, but the list of outputs is quite extensive and could be structured into bullet points for easier scanning. Overall, it is still concise and to the point.

  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 covers the main functionality and outputs comprehensively, listing all major audit components. It does not mention the output format or any limitations, but since there is no output schema, this is not strictly required. Given the complexity, the description is fairly complete, though it could benefit from a note about response structure.

  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% (all three parameters have descriptions), so the baseline is 3. The tool description does not add extra semantic detail about parameters beyond what the schema already provides. The schema itself adequately explains 'url', 'psi_key', and 'estrategia'.

  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: it audits a website using the official SAG RANK algorithm. It enumerates the specific outputs (Global Score, Core Web Vitals, SEO On-Page, AEO, GEO, AI bot status, SPA/CSR detection, optimization priorities), making the functionality unambiguous. This distinctively differentiates it from sibling tools like 'compare' or 'generate_fixes'.

  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 does not provide explicit guidance on when to use this tool versus the siblings. It does not mention scenarios such as 'use for a comprehensive audit' or 'use sagrank_compare for side-by-side comparisons'. The list of features implies a full audit, but no direct comparison or exclusion is given.

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

• sagrank_check_ai_crawlersB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It states the action (checks robots.txt) and the output (status per crawler) but does not mention whether the operation is read-only, if it requires permissions, what happens if robots.txt is missing, or any side effects. This leaves the agent without key behavioral 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?

  The description is a single, well-structured sentence that front-loads the main purpose, lists the specific crawlers, and states the output. No filler or redundancy; every word contributes to understanding.

  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 lack of an output schema, the description adequately explains what the tool returns (status and exact directives). It covers the scope (8 crawlers) and the action. However, it does not address edge cases like missing robots.txt, redirects, or error handling, but for a focused check tool this is a minor gap.

  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 covers the single parameter (url) with a clear description ('La URL o dominio del sitio web a inspeccionar.'). The tool description does not add additional meaning beyond that, but with 100% schema coverage, the baseline of 3 is appropriate. No extra guidance on URL format or validation is provided.

  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 function: checking the access status of 8 specific AI crawlers in a website's robots.txt, and it explicitly lists the crawlers and the types of outcomes (Permitidos, Bloqueados, Restringidos). This verb+resource specificity distinguishes it from siblings like sagrank_audit (broader audit) and sagrank_compare (comparison).

  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 does not mention when to use this tool versus alternatives, nor does it provide any exclusions or context for selection. It simply describes the action without guiding the agent on appropriate scenarios or trade-offs compared to sibling tools.

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

• sagrank_compareA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry full responsibility for disclosing side effects, permissions, or non-destructive behavior. It only describes the output (a comparison table) without mentioning whether it performs read-only analysis, accesses external APIs (other than the optional PSI key), or has rate limits.

  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 a single, well-organized sentence that lists all comparison dimensions. It is slightly verbose due to the detailed enumeration, but remains focused and easy to parse.

  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 provides a full picture of what the tool does and what output to expect (comparison table, winner, strengths). It does not mention any prerequisites or dependencies, but these are not necessary for the core understanding.

  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 already provides clear descriptions for all 4 parameters (url1, url2, psi_key, estrategia) with enum values for estrategia. The description adds no additional meaning to the parameters, so it stays at the baseline for fully covered schemas.

  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 explicitly states the tool's function: comparing two websites and generating a side-by-side comparison table. It is distinct from sibling tools (audit, check_ai_crawlers, generate_fixes) by clearly targeting pairwise competitive analysis.

  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 implicitly defines the use case: use when you need a competitive head-to-head comparison of two sites. However, it does not explicitly contrast with siblings (e.g., 'use this instead of sagrank_audit when comparing two URLs'), leaving some room for inference.

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

• sagrank_generate_fixesA
  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 must carry the full burden. It states that it generates code and files, but does not clarify whether it writes to the filesystem or returns the content, nor does it mention side effects, authentication, or rate limits. The behavior is partially transparent.

  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 and well-structured, consisting of two sentences that efficiently convey the tool's purpose and the three deliverables. No unnecessary fluff or redundancy.

  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?

  For a simple tool with 3 parameters and no output schema, the description provides enough context to understand what the tool does and what it produces. It does not specify return format or error handling, but these are not critical for basic usage. The listing of the three outputs gives sufficient completeness.

  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 parameters (url, descripcion, nombre_sitio) with clear meaning. The tool description text itself does not add extra parameter semantics beyond what the schema already provides, so a baseline score 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 clearly states the tool generates production-ready code and files to fix problems detected by SAG RANK, and explicitly lists the three specific outputs (llms.txt, Schema.org JSON-LD, robots.txt). This distinguishes it from sibling audit/compare/check tools.

  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 implies usage when issues are found by SAG RANK audit, but does not explicitly mention alternatives or prerequisites. It gives enough context for an agent to infer when to use this tool versus the audit/compare tools.

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