Server Quality Checklist

Tool Scores

• jira_readA
  3.6/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 declares the tool 'safe, read-only', which is good. However, it does not disclose error behavior for invalid operations, permission requirements, or rate limits. The example shows correct usage but lacks edge-case 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 three sentences plus an example, all essential. The purpose is front-loaded, and the example clarifies usage immediately. No redundant words; every sentence adds value.

  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 description covers the two parameters adequately and provides an example. However, there is no output schema and the description does not mention the return format, potential errors, or pagination. For a read tool, omitting the return structure is a notable gap.

  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?

  Schema coverage is 0% (no descriptions in schema), so the description compensates. It explains that 'operation' selects the read operation and 'params' is a JSON object with parameters. The mention of operation='help' and the example add concrete meaning beyond the bare schema types.

  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 'Query Jira data (safe, read-only)', which identifies the verb and resource. It distinguishes from sibling tools like jira_write and jira_delete by explicitly marking itself as read-only. However, it could be more specific about which Jira entities are queried, though the example helps.

  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 advises calling with operation='help' to list available operations, which provides a discovery mechanism. It does not explicitly contrast with siblings, but they are clearly different (write, execute, delete). No explicit when-to-use or when-not-to-use guidance beyond the 'read-only' hint.

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

• jira_writeA
  3.7/5.0
  Behavior2/5

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

  No annotations provided, so description must cover behavioral traits. Only states 'non-destructive', which is useful but insufficient. Does not disclose error handling, side effects, or authentication requirements.

  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?

  Very concise: one line for purpose, one for help mechanism, one for example. Every sentence provides essential information with no 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 moderate complexity (2 params, no output schema, no annotations), the description covers the operation dispatch pattern and usage example. Could mention return format or error cases, but overall sufficient.

  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?

  Schema coverage is 0%, so description must add meaning. Explains that operation can be 'help' or a specific operation name, and params is a JSON object. Example clarifies usage. Adds significant value beyond schema.

  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?

  Clearly states 'Create or update Jira resources (non-destructive)', which specifies verb and resource. However, does not differentiate from sibling tools like jira_execute, leaving ambiguity about when to use this tool over alternatives.

  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?

  Provides explicit guidance to call with operation='help' to list operations, and includes an example. Lacks explicit when-not-to-use or comparisons with siblings, but the help mechanism compensates.

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

• jira_deleteA
  4.1/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses the key behavioral traits: destructive and irreversible. This is critical for a deletion tool, though it lacks mention of authentication or error 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?

  Three sentences with clear front-loading: 'Delete Jira resources (destructive, irreversible).' Every sentence serves a purpose—identifying action, usage hint, and example.

  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?

  Missing output schema and no description of return values or error handling. The help mechanism partially compensates, but for a destructive tool, more context on success/failure would improve 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?

  With 0% schema coverage, the description adds an example (DeleteIssue with issue_key) but does not explain the structure of params or list all operations. It provides a help mechanism but no detailed parameter 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 deletes Jira resources and emphasizes it is destructive and irreversible. It distinguishes from siblings like jira_read, jira_write, and jira_execute by focusing solely on deletion.

  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?

  Provides explicit guidance to call with operation='help' to list available delete operations, and includes a concrete example. However, it does not specify when not to use this tool or alternatives for non-destructive actions.

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

• jira_versionA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description carries the burden. It accurately states the tool retrieves version and status without side effects. Could mention authentication or availability, but sufficient for a simple read-only 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?

  Single concise sentence front-loading the purpose with zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no parameters, no output schema, and simple purpose, the description is entirely sufficient for an agent to use correctly.

  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?

  No parameters exist, so schema coverage is 100%. Baseline for 0 params is 4; description adds no param info, but none is needed.

  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 specific verb 'Get' and resource 'Jira MCP server version and service status', clearly distinguishing from sibling tools like jira_write or jira_delete.

  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?

  No explicit guidance on when to use this tool versus alternatives; usage is implied by the purpose but lacks direct context or exclusions.

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

• jira_executeA
  4.7/5.0
  Behavior4/5

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

  The description explicitly states these are side-effects on existing issues, indicating mutational behavior. Without annotations, it carries the burden and does so adequately. However, it does not detail authorization needs or specific impacts beyond 'state changes', which would be beneficial.

  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 sentences plus an example, all front-loaded with the core purpose. Every sentence adds value: purpose, sibling differentiation, help suggestion, and illustrative example. No wasted words.

  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 tool with only 2 parameters and no output schema, the description covers the main usage pattern and provides a discovery mechanism (help). It could mention return values or list common operations, but it's mostly complete for initial use.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must compensate. It explains that params is a flexible object depending on the operation and provides a concrete example with 'issue_key' and 'transition_id'. This adds significant meaning beyond the bare 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 tool triggers Jira state changes (transition, assign, unassign), with a specific verb and resource. It distinguishes itself from siblings by explicitly contrasting with jira_write as side-effects on existing issues rather than resource creation.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use advice: 'Distinct from write because these are side-effects on existing issues rather than resource creation.' It also suggests calling with operation='help' to list all available operations, guiding the agent on how to discover usage.

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