Server Quality Checklist

Tool Scores

• delete_wiki_pageB
  3.1/5.0
  Behavior2/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Delete' without noting irreversibility, permission requirements beyond the token scope, or potential side effects like cascading changes to wiki structure.

  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, clear sentence that efficiently conveys the core purpose. It is front-loaded and wastes no words, though it may be slightly too terse given the lack of supplementary context.

  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 destructive operation with 5 parameters and no annotations or output schema, the description is insufficient. It omits important context such as the commit message default, the permanent nature of deletion, and error handling behavior.

  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 all parameters with descriptions, so the baseline is 3. The tool description adds no additional semantic meaning beyond what the schema already provides.

  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 action ('Delete') and the resource ('a wiki page from a GitHub repository wiki'), making it unambiguous and distinct from sibling tools like write, read, append, and list.

  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, no mention of prerequisites or situations where deletion is appropriate. The description simply states what it does without context.

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

• read_wiki_pageA
  3.7/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 the burden. It clearly states the core behavior (reading content) and adds 'existing' to indicate it does not create pages. However, it does not disclose return format, error behavior for missing pages, or any permissions/rate-limit implications beyond the token in the schema. Basic transparency for a read operation, but lacking depth.

  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 that directly states the tool's purpose without any redundant information. It is appropriately minimal and front-loaded.

  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?

  The tool has four required parameters and no output schema or annotations. The description explains what the tool does but does not describe the return value (e.g., content format, metadata), error conditions (e.g., page not found), or when to use it alongside siblings. Given the simplicity of the operation, this is sufficient for a basic read, but it lacks some 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?

  Schema description coverage is 100%, so all four parameters (owner, repo, token, pageName) are already described at the schema level. The description adds no additional meaning beyond what the schema provides, so the 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 uses a specific verb ('Read') and resource ('GitHub wiki page'), and adds 'existing' to clarify it does not create or modify. This clearly distinguishes it from siblings like write_wiki_page, append_to_wiki_page, delete_wiki_page, and list_wiki_pages.

  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 phrase 'existing GitHub wiki page' implies the tool is for reading pages that already exist, but it does not explicitly say when to use it over alternatives, nor does it mention that list_wiki_pages could be used to discover page names. Usage context is implied by the tool name and sibling set, but no explicit guidance is provided.

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

• list_wiki_pagesA
  3.8/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 the full burden. It states the operation (list all wiki pages) and hints at exhaustive results ('all'), but does not disclose return format, pagination behavior, or any edge cases. It is not contradictory, but offers only minimal 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, front-loaded sentence with no filler. Every word is informative, making it concise and well-structured.

  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 read-only listing tool with no output schema, the description is largely sufficient: it clearly indicates the action and scope. However, it omits any mention of the response format (e.g., list of page titles or slugs), which would be needed for a fully self-contained description, but the simplicity of the tool keeps this from being a major 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 input schema describes all three parameters (owner, repo, token) with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning, only restating that it lists wiki pages in a repository.

  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 'List' and the resource 'all wiki pages in a GitHub repository wiki'. It distinguishes from sibling tools (write, read, append, delete) by explicitly focusing on listing all pages.

  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 gives no explicit guidance on when to use this tool versus alternatives. The intended use is implied by the name and description, but no when-not-to-use or alternative tools are mentioned, so it remains at an implied level.

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

• write_wiki_pageA
  3.8/5.0
  Behavior4/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 disclosing behavioral traits. It clearly states the destructive action of overwriting an existing page, which is the most important behavioral characteristic. It does not mention other aspects like auth requirements, rate limits, or return values, but the schema already covers the token parameter and no output schema exists.

  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 long, front-loaded with the core purpose, and every sentence earns its place. It efficiently conveys the key functional scope and behavior without 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?

  Given the rich schema (100% parameter coverage) and the absence of an output schema, the description covers the essential behavior of creating or overwriting a wiki page. It could be more complete by explicitly directing users to append_to_wiki_page when they want to preserve existing content, but the overwrite language already implies this distinction.

  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 all six parameters documented in the input schema. The description adds minimal parameter semantics beyond referencing 'provided content' for the content parameter, so it stays at 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 writes or updates a GitHub wiki page, with explicit coverage of creating new pages or overwriting existing ones. It uses a specific verb+resource (write/update wiki page) and partially distinguishes from siblings by noting the overwrite behavior, but it does not explicitly name alternative tools like append_to_wiki_page.

  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?

  Usage is implied through the overwrite behavior: the description says it 'overwrites an existing one,' suggesting it is not for appending. However, it does not explicitly state when to use this tool versus alternatives such as append_to_wiki_page, nor does it provide prerequisites or exclusions.

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

• append_to_wiki_pageA
  4/5.0
  Behavior4/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 reveals a non-obvious trait: the tool creates the page if it does not exist, which is more than the name alone suggests. However, it does not mention error conditions, permission checks (beyond token schema), or response structure, slightly limiting 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, using two short sentences that front-load the primary action and then add the fallback behavior. Every word earns its place, with no extraneous content.

  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 append operation, the description covers the core behavior and the schema covers all parameters. No output schema is needed. The only gaps are minor edge cases (e.g., empty content, encoding) and explicit comparison with siblings, but overall it is sufficiently complete given the tool's simplicity.

  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 baseline is 3. The description reinforces that 'content' is appended and 'pageName' is the target, but it does not add parameter-specific details beyond the schema. This is acceptable since the schema already documents each parameter well.

  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 a specific action ('Append content to an existing wiki page') with a defined resource ('wiki page'). The fallback behavior ('If the page does not exist, creates it') further distinguishes it from the sibling 'write_wiki_page', which implies overwriting rather than appending.

  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 behavior implies usage – you use it when you want to add content without replacing existing content – but it does not explicitly compare against alternatives like 'write_wiki_page' or specify when to prefer one over the other. There are no exclusions or prerequisites beyond what the schema already notes.

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