Server Quality Checklist

Tool Scores

• list_sprintsB
  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 must carry the full burden of behavioral disclosure. It mentions that state accepts specific values and comma-separated lists, but does not explain behavior around the optional board_id, pagination via limit, or any potential side effects. The 'on a board' phrasing may conflict with board_id being optional (default null).

  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 every word adds value. It avoids redundancy and is appropriately sized for the tool's simplicity.

  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 is relatively simple and an output schema exists, so return values need not be described. However, the description lacks guidance on optional parameters and usage context, making it minimally viable but with noticeable gaps in board_id handling and when to use this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the 'state' parameter's allowed values and comma-separation, but does not add meaning for 'board_id' or 'limit'. Board_id's optionality and semantics (null meaning all boards?) are left ambiguous.

  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 lists sprints on a board, with the specific purpose of picking sprint IDs. It distinguishes itself from sibling tools like get_sprint_issues by focusing on sprint enumeration rather than issue retrieval.

  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 'so you can pick sprint ids' implies usage as a precursor to other tools, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. This is implied usage rather than explicit guidance.

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

• check_confluence_capabilitiesB
  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 carries full burden for behavioral disclosure. It does not mention whether this is a read-only operation, whether it makes network calls, or how the optional space_key parameter affects behavior. It only states what it reports, leaving side effects and safety unclear.

  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 minimal and front-loaded: the first sentence states the core purpose and specific outputs, and the second sentence gives a clear usage directive. Every word earns its place with no repetition 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's low complexity and the presence of an output schema, the description adequately covers purpose and usage. However, it omits explanation of the space_key parameter and does not disclose behavioral traits beyond reporting, which are gaps in an otherwise simple tool. The description is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage for space_key, and the description does not mention space_key at all. The agent receives no guidance on what the parameter means, why it is optional, or what value to provide. The description fails to compensate for the lack of schema descriptions.

  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 a specific verb ('Report') and resource ('what this Confluence instance supports for interactive tables'), and it lists the exact details it reports (deployment flavour and app installation). This distinguishes it from sibling tools like check_connection, which likely checks connectivity rather than capabilities.

  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?

  'Use before choosing table_style' provides an explicit usage context, telling the agent when to invoke this tool. However, it does not mention alternatives or when not to use it, such as comparing it to check_connection, leaving some ambiguity.

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

• get_developer_sprint_historyA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does add valuable behavioral details: it uses the Jira changelog to compute accurate metrics and produces a flat table with developer as a column. However, it does not disclose permissions, rate limits, or any limitations (e.g., what happens with invalid sprint IDs), leaving gaps 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 highly concise, with three sentences that all add distinct value: the core function, the data-source advantage, and the output format. Information is front-loaded and no sentence is redundant.

  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?

  Despite having an output schema, the description remains incomplete because it does not guide parameter selection or workflow. An agent cannot reliably construct a call for this 9-parameter tool without documentation on how sprint_ids, include_issue_detail, publish, and other fields should be used. The description covers the 'why' but not the 'how'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description makes no attempt to explain any of the 9 parameters. It does not clarify the role of sprint_ids (beyond obvious inference), publish, include_unassigned, table_style, or any other parameters, so the agent is left with schema names only.

  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 as a 'multi-sprint rollup grouped by developer', which is specific and distinctive. It uses an action-oriented phrasing ('rollup') and names the resource (developers and sprints), effectively distinguishing it from sibling tools like get_sprint_issues or list_sprints.

  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 usage context by specifying a useful sprint range ('2-5 sprints') and indicating the tool is for multi-sprint analysis. However, it does not explicitly mention when not to use it or point to alternatives, so it lacks explicit exclusions.

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

• get_refinement_readiness_reportA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the default checks, the option to add 'description', and the scope parameter. However, it omits behavioral traits such as whether the tool can publish results (given the 'publish' parameter) or if it has side effects, leaving gaps 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 one concise sentence that front-loads the main purpose, then adds key parameter details. Every clause adds value without redundancy or fluff.

  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?

  The tool has 13 parameters, no annotations, and no schema descriptions. The description only covers a small fraction of the parameter space and omits important context like the publish option and how it relates to sibling tools such as publish_confluence_page. This is inadequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must compensate. It only explains 'scope' and 'checks', while 11 other parameters (e.g., publish, board_id, page_title, include_confluence_storage) remain undocumented. This is insufficient for a tool with 13 parameters.

  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 produces a 'refinement readiness report' identifying stories missing estimates and DOR/DOD labels, plus a suggested attendee list. It is specific about the resource and differentiates from sibling tools like list_sprints and get_sprint_issues, which focus on different data.

  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: it is a weekly report for refinement meetings, and it explains the two scope options ('backlog' or 'sprint'). However, it does not explicitly mention when not to use it or name alternative tools, so it lacks explicit exclusions.

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

• get_sprint_issuesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the side effect of publish=true writing to Confluence and the returned fields. However, it omits details on authentication, error behavior, pagination, or the consequences of publishing (e.g., overwrite vs create new page), leaving gaps in behavioral 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 three compact sentences with no filler. It front-loads the core functionality and adds the publish caveat prominently, making it easy 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?

  With 10 parameters, no annotations, and 0% schema coverage, the description is not complete. It covers the filtering and publish aspects but leaves the Confluence-related parameters unexplained, making it hard for an agent to correctly invoke the tool with all necessary details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, so the description must compensate. It clarifies statuses, status_categories, and publish, but fails to explain the remaining 7 parameters (e.g., space_key, page_title, project_key, table_style, parent_page_id, include_confluence_storage), which is a significant gap given the tool's complexity.

  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 issues in a sprint, distinguishing it from sibling tools like list_sprints (which lists sprints) and publish_confluence_page (which publishes pages). It also mentions the optional filtering and publishing side-effect, giving a specific verb+resource description.

  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: to get issues in a sprint with optional filtering by status or status category, and to optionally publish to Confluence via publish=true. It provides clear context but does not explicitly state when to prefer this over alternatives like get_refinement_readiness_report or publish_confluence_page.

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

• publish_confluence_pageA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of disclosure. It discloses the key behavioral traits: creation vs. overwrite, update-by-title, and a specific body format requirement. However, it does not mention permissions, reversibility, or what happens to space_key/parent_page_id when left at defaults, which would be valuable for a mutation tool.

  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 every clause adds necessary detail. There is no fluff or repetition of the schema.

  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?

  Although an output schema exists (so return values are covered), the tool has 4 parameters, a mutation risk, and no annotations. The description omits the semantics of space_key and parent_page_id, and does not explain the creation flow when no parent is specified. This leaves meaning gaps for an AI agent trying to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, but it only explains two of the four parameters. It clarifies body format (XHTML) and source (`confluence` value), and how title drives the update. Space_key and parent_page_id are entirely underexplained beyond their schema names/defaults.

  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 begins with 'Create or overwrite a Confluence page', a specific verb+resource that immediately distinguishes it from sibling tools like check_connection or list_sprints. It also explains the update-by-title behavior, making the purpose unambiguous.

  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?

  It gives concrete guidance: body must be Confluence storage format and the `confluence` value should come from a report. This implies the primary use case (publishing report output), but it does not explicitly state when not to use the tool or name alternatives, 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.

• check_connectionA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It uses 'verify' and 'show' which imply a read-only operation, but it does not explicitly state that no data is modified or describe error behavior. This leaves some ambiguity about side effects and failure handling.

  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: the first states the purpose and output, the second provides usage guidance. It is concise, front-loaded, and contains 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?

  For a simple connection check with an output schema present, the description covers the essential aspects: what credentials are verified, what configuration is shown, and when to run it. It does not address failure scenarios or assumptions, but these are minor gaps for this tool type.

  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 tool has zero parameters, so schema coverage is trivially 100%. The description correctly does not add parameter details, and the baseline of 4 is appropriate because there is nothing to explain.

  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 verifies Jira and Confluence credentials and displays resolved configuration details (base URLs, deployment flavour, story points field, defaults). This specific verb+resource combination distinguishes it from sibling tools like check_confluence_capabilities, which focuses on capabilities rather than credentials and configuration.

  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 explicitly says 'Run this first on a new instance,' providing clear context for when to use it. However, it does not mention alternatives or when not to use it, 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.