Server Quality Checklist

Tool Scores

• create_issueC
  2.9/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 states the tool creates an issue and returns details, but lacks critical information: it doesn't mention authentication requirements, rate limits, whether the operation is idempotent, or potential side effects (e.g., notifications). For a mutation tool with zero annotation coverage, this is inadequate.

  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, efficient sentence that front-loads the core action ('Create a new issue/ticket in Redmine') and adds a useful note about the return value. There's no wasted verbiage, though it could be slightly more structured (e.g., separating purpose from output).

  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 complex mutation tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format beyond 'ID and details', lacks error handling or permission context, and omits behavioral traits. Given the richness needed, it falls short of providing complete guidance.

  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 description coverage is 100%, with all 11 parameters well-documented in the input schema (e.g., 'project_id' as 'The ID of the project to create the issue in'). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

  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 ('Create a new issue/ticket') and resource ('in Redmine'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'update_issue' or 'delete_issue' by specifying creation. However, it doesn't explicitly differentiate from all siblings (e.g., 'add_comment' also creates something), so it's not a perfect 5.

  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 provides no guidance on when to use this tool versus alternatives like 'update_issue' or 'search_issues'. It mentions the return value but doesn't specify prerequisites (e.g., needing a project ID) or contextual constraints, leaving the agent to infer usage from the tool name alone.

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

• delete_issueC
  2.9/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 states the tool deletes an issue, implying a destructive mutation, but lacks critical details: it doesn't specify if deletion is permanent/reversible, what permissions are required, if there are side effects (e.g., cascading deletions), or what the response looks like (e.g., success/failure indicators). For a destructive tool, this is a significant gap 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 a single, direct sentence with zero wasted words. It front-loads the key action ('Delete') and resource, making it immediately understandable. Every part of the sentence earns its place by specifying the tool's core function efficiently.

  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 tool's complexity (destructive mutation with no annotations and no output schema), the description is incomplete. It lacks behavioral details like permanence, permissions, or response format, and doesn't compensate for the absence of annotations or output schema. This leaves the agent with insufficient context for safe and effective use.

  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 has 100% description coverage, with the single parameter 'issue_id' fully documented in the schema. The description adds no additional parameter semantics beyond implying the ID is for deletion, which is already clear from the schema. This meets the baseline of 3 for high schema coverage, but no extra value is provided.

  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 ('Delete') and resource ('a Redmine issue/ticket by ID'), making the purpose unambiguous. It distinguishes from siblings like 'create_issue' or 'update_issue' by specifying deletion. However, it doesn't explicitly mention that this is a destructive operation beyond the verb 'Delete', which slightly limits differentiation from non-destructive siblings like 'get_issue'.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing issue existence or permissions), exclusions (e.g., not for bulk deletion), or direct alternatives (e.g., 'update_issue' to close instead). This leaves the agent with minimal context for tool selection.

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

• get_issuesC
  2.9/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 the full burden of behavioral disclosure. It mentions 'Returns paginated results with issue details including status, priority, assignee, and more,' which adds some context on output format and pagination. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only operation, leaving significant gaps for a tool with no annotation coverage.

  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 concise and front-loaded, with two sentences that efficiently convey the core functionality and output. There is no wasted text, and it avoids redundancy, making it easy to parse quickly for an AI agent.

  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 (5 parameters, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and output format but lacks details on usage guidelines, behavioral traits, and parameter nuances. Without an output schema, it partially describes return values, but more context is needed for full agent 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?

  Schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema by mentioning 'optional filters' and listing example fields in the output, but it does not provide additional semantics for parameters like filter combinations or default behaviors. 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: 'Get a list of Redmine issues/tickets with optional filters.' It specifies the verb ('Get'), resource ('Redmine issues/tickets'), and scope ('list'), but does not explicitly differentiate from sibling tools like 'get_issue' (singular) or 'search_issues', which might have overlapping functionality. This makes it clear but not fully distinct from alternatives.

  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 provides no guidance on when to use this tool versus alternatives. It mentions 'optional filters' but does not specify scenarios, prerequisites, or exclusions, such as when to choose 'get_issues' over 'search_issues' or 'get_issue'. Without this context, the agent lacks direction for tool selection among siblings.

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

• get_projectC
  2.9/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 states it retrieves 'detailed information,' implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'detailed' entails (e.g., fields returned). This leaves significant gaps for a tool with no annotation coverage.

  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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool, making it easy to parse and understand 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?

  Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like response format or error cases, which are crucial for an agent to use it effectively, especially with no structured output guidance.

  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 description coverage is 100%, with the parameter 'project_id' fully documented in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain ID formats or sources), so it meets the baseline score of 3 where the 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 with a specific verb ('Get') and resource ('detailed information about a specific Redmine project'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_projects' (which likely lists multiple projects), so it misses the highest score for sibling differentiation.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_projects' for listing projects or 'get_project_members' for project details, nor does it specify prerequisites or exclusions, leaving the agent to infer usage from context alone.

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

• get_project_versionsC
  2.9/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 the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, pagination, or response format. For a read operation with zero annotation coverage, this leaves critical behavioral traits unspecified.

  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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'version' entails, the return format, or any error conditions. For a tool in a complex project management context, more detail is needed to guide effective use.

  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 the single parameter 'project_id'. The description adds no additional meaning beyond implying the parameter is required, which is already clear from the schema. 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 verb ('Get') and resource ('list of versions for a specific project'), making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_project' or 'get_issues', which also retrieve project-related data, leaving room for ambiguity in a crowded toolset.

  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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_project' and 'get_issues' available, it fails to specify scenarios where retrieving versions is preferred over other project data, offering no exclusions or contextual advice.

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

• log_timeC
  2.9/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 the full burden of behavioral disclosure. It states the tool logs time stats, implying a write operation, but does not disclose critical traits like authentication needs, rate limits, whether it creates new entries or updates existing ones, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

  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, efficient sentence: 'Log time stats for an issue or project.' It is front-loaded with the core purpose and contains no unnecessary words, making it highly concise and well-structured.

  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 tool's complexity (a mutation tool with 6 parameters), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like permissions, side effects, or return values, leaving significant gaps for an AI agent to understand how to use it correctly.

  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 6 parameters with clear descriptions. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., that 'issue_id' or 'project_id' is needed but not required in schema). Baseline 3 is appropriate when the 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: 'Log time stats for an issue or project.' It uses a specific verb ('log') and identifies the resource ('time stats'), but does not distinguish it from sibling tools like 'get_time_entries' or 'get_time_entry_activities', which reduces the score from a 5.

  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 provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_time_entries' (for retrieving time logs) or 'add_comment' (for adding comments without time logging), nor does it specify prerequisites or exclusions, such as requiring an issue or project ID.

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

• update_issueC
  2.9/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 states 'Only provided fields will be updated,' which is useful partial behavior disclosure (partial updates). However, it doesn't mention authentication requirements, error conditions, whether updates are reversible, rate limits, or what the response looks like (no output schema). For a mutation tool with 13 parameters, this leaves significant behavioral 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 extremely concise with just two sentences that are front-loaded with the core purpose. Every word earns its place—the first sentence states what the tool does, and the second adds important behavioral context about partial updates. There's zero redundancy or unnecessary elaboration.

  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 complexity (13 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. While it states the purpose and partial update behavior, it doesn't cover authentication needs, error handling, response format, or usage guidelines relative to siblings. For a tool that modifies existing issues, this leaves the agent with insufficient context 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%, so the schema fully documents all 13 parameters with clear descriptions. The description adds no parameter-specific information beyond the general 'Only provided fields will be updated' statement, which reinforces the partial update behavior but doesn't provide additional semantic context for individual parameters. 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 action ('Update') and target resource ('an existing Redmine issue/ticket'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'create_issue' or 'add_comment', but the 'existing' qualifier provides some distinction. The purpose is specific but could be more distinctive.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing issue_id), when to choose update_issue over create_issue for modifications, or how it differs from add_comment for adding notes. The agent must infer usage from the tool name and parameter list alone.

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

• get_issueB
  3.2/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 the full burden. It mentions what information is included ('journals (history), attachments, and relations'), which adds useful context beyond a basic read operation. However, it doesn't disclose behavioral traits like error handling (e.g., what happens if the ID is invalid), authentication needs, rate limits, or response format. For a read tool with zero annotation coverage, this 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose and adds clarifying details about included data. There's no wasted wording, but it could be slightly more structured (e.g., separating purpose from inclusions). Overall, it's appropriately sized and earns its place.

  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 (single parameter, read-only operation) and 100% schema coverage, the description is adequate but incomplete. No output schema exists, so the description should ideally explain return values more thoroughly (e.g., format, fields). It mentions included data types but lacks depth on behavioral aspects like errors or auth. For a read tool with no annotations, this is minimally viable but has clear gaps.

  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 has 100% description coverage, with the single parameter 'issue_id' documented as 'The ID of the issue to retrieve.' The description adds no additional parameter semantics beyond this, as it doesn't explain ID format, constraints, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra details.

  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: 'Get detailed information about a specific Redmine issue/ticket by ID.' It specifies the verb ('Get'), resource ('Redmine issue/ticket'), and scope ('by ID'). However, it doesn't explicitly differentiate from sibling tools like 'get_issues' (which likely lists multiple issues) or 'search_issues' (which might support filtering), though the 'specific' and 'by ID' wording implies a single-item lookup.

  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: it's for retrieving a single issue when you know its ID. It doesn't explicitly state when not to use it (e.g., vs. 'get_issues' for listing or 'search_issues' for filtering by other criteria) or name alternatives. The 'specific' and 'by ID' phrasing provides some guidance but lacks explicit comparisons or exclusions.

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

• get_projectsB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses pagination behavior and that it returns 'project details', which adds value beyond the input schema. However, it doesn't cover critical aspects like authentication requirements, rate limits, error conditions, or what specific details are included in the response, leaving significant gaps for a read operation.

  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 two concise sentences that efficiently state the core functionality and key behavioral trait (pagination). It's front-loaded with the main purpose. However, it could be slightly more structured by explicitly separating purpose from behavior.

  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 read-only list tool with 2 parameters and no output schema, the description is minimally adequate. It covers the purpose and pagination but lacks details on response format, error handling, and usage context relative to siblings. Without annotations or output schema, more behavioral context 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?

  Schema description coverage is 100%, so the schema fully documents both parameters (limit and offset). The description adds no parameter-specific information beyond what's in the schema, but doesn't need to compensate for gaps. The baseline of 3 is appropriate when the schema does all the work.

  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 verb ('Get') and resource ('list of all Redmine projects'), making the purpose specific and understandable. It distinguishes from sibling 'get_project' (singular) by indicating it returns multiple projects, but doesn't explicitly contrast with other list tools like 'get_issues' beyond the resource type.

  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 provides no guidance on when to use this tool versus alternatives like 'get_project' (for a single project) or 'search_issues' (which might filter projects indirectly). It mentions pagination but doesn't explain when paginated listing is preferred over other retrieval methods.

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

• get_time_entry_activitiesB
  3.2/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 the full burden of behavioral disclosure. It mentions retrieving a list but doesn't specify if this is a read-only operation, if it requires authentication, how data is formatted (e.g., pagination, sorting), or potential errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  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, efficient sentence that front-loads the core purpose ('Get list of time entry activities') and includes helpful examples without unnecessary details. Every word earns its place, making it highly concise and well-structured.

  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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on usage context, behavioral traits, or output format. Without annotations or an output schema, the description should ideally provide more context about the return data, but it meets the basic requirement for a simple retrieval tool.

  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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description adds value by providing examples ('e.g. Design, Development') that clarify the semantics of the returned data, which goes beyond the empty schema. This justifies a score above the baseline of 3 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 action ('Get list') and resource ('time entry activities'), with examples that clarify the type of data returned. However, it doesn't explicitly differentiate from sibling tools like 'get_time_entries' or 'get_issues', which might also involve time-related data retrieval.

  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. For instance, it doesn't mention if this is for retrieving metadata (activities) versus actual time entries (handled by 'get_time_entries') or how it relates to other tools like 'log_time' for time logging. The description only states what it does, not when it's appropriate.

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

• get_time_entriesB
  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 the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe key traits such as pagination behavior (implied by 'limit' and 'offset' in schema but not explained), authentication needs, rate limits, or what happens if no filters are applied (e.g., retrieves all entries). This leaves significant gaps for an agent to understand operational behavior.

  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, efficient sentence that front-loads the core purpose ('Get time entries logged in Redmine') and adds essential filtering information. There is no wasted text, repetition, or unnecessary elaboration, 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 (6 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and filtering scope but lacks details on behavioral aspects like response format, error handling, or pagination, which are critical for a retrieval tool with multiple parameters. Without annotations or output schema, more context 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?

  Schema description coverage is 100%, so the schema fully documents all 6 parameters with clear descriptions and constraints (e.g., date formats, numeric ranges). The description adds minimal value beyond the schema by listing filterable fields ('project, user, and date range'), but doesn't provide additional context like parameter interactions or default behaviors. 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 action ('Get time entries') and resource ('logged in Redmine'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'log_time' (which creates entries) and 'get_issues' (which retrieves different data). However, it doesn't specify if this retrieves all entries or only filtered ones, which slightly reduces specificity.

  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 through the mention of filtering options ('Can be filtered by project, user, and date range'), suggesting this tool is for retrieving time entries with optional filters. However, it doesn't explicitly state when to use this versus alternatives like 'get_issues' for issue-related data or 'log_time' for creating entries, nor does it provide exclusions or prerequisites.

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

• search_issuesB
  3.3/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 discloses key behavioral traits: it performs a search (implying read-only, non-destructive), specifies the search field (subject), and mentions pagination. However, it lacks details on permissions, rate limits, error handling, or the exact format of paginated results.

  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 and front-loaded: two sentences that directly state the tool's function and key behavior (paginated results). Every word earns its place, with no redundant or vague phrasing.

  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 no annotations and no output schema, the description is moderately complete for a search tool. It covers the basic operation and pagination but omits details like result format, error cases, or authentication needs. For a tool with 3 parameters and 100% schema coverage, it's adequate but could be more informative about behavioral aspects.

  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 parameters (query, limit, offset). The description adds minimal value beyond the schema—it implies 'query' is for keyword matching in subjects but doesn't explain syntax or provide examples. Baseline 3 is appropriate as the schema handles most of the documentation.

  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: 'Search for Redmine issues/tickets by keyword in the subject field.' It specifies the verb (search), resource (issues/tickets), and scope (subject field). However, it doesn't explicitly differentiate from sibling tools like 'get_issues' or 'get_issue', which likely retrieve issues without searching.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_issues' (which might list all issues) or 'get_issue' (which retrieves a specific issue by ID), leaving the agent to infer usage from context alone.

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

• add_commentA
  3.5/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 the full burden. It mentions the tool is for 'adding comments' which implies a write operation, but lacks details on permissions required, rate limits, error handling, or what happens on success (e.g., does it return the updated issue?). For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.

  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 with zero waste: the first states the purpose, and the second adds valuable usage context. It's appropriately sized and front-loaded, earning a perfect score for efficiency.

  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 moderate complexity (a write operation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers purpose and basic usage but lacks details on behavioral aspects like permissions or response format, leaving gaps that could hinder an agent's effective use.

  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 both parameters (issue_id and notes) adequately. The description adds no additional parameter semantics beyond what's in the schema, such as format constraints or examples, resulting in the baseline score of 3.

  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 ('Add a comment/note') and target resource ('to an existing Redmine issue'), distinguishing it from siblings like create_issue or update_issue. However, it doesn't explicitly differentiate from update_issue which might also allow commenting, making it slightly less specific than a perfect 5.

  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's for 'a simple way to add comments without updating other issue fields,' implying this tool should be used when only commenting is needed versus update_issue which might modify other fields. It doesn't explicitly name alternatives or state when-not to use it, so it falls 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.

• get_project_membersA
  3.5/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 discloses key behavioral traits: the tool returns paginated results and includes member details, user info, and roles. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if the project doesn't exist. For a read operation with no annotations, this is adequate but lacks 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 two sentences with zero waste: the first states the purpose and resource, the second specifies the return format and pagination. It's front-loaded with the core action and efficiently conveys essential information 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?

  Given no annotations and no output schema, the description provides basic completeness for a read operation: it states what the tool does and the return structure. However, it lacks details on authentication, error handling, or response format specifics, which could be important for an agent invoking this tool in a Redmine context.

  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 three parameters (project_id, limit, offset). The description adds no parameter-specific information beyond implying pagination through 'Returns paginated results,' which is already covered by the offset parameter's description. 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Get a list'), resource ('project members in a specific Redmine project'), and scope ('paginated results with member details, user info, and their roles'). It distinguishes this from sibling tools like get_project or get_issues by focusing specifically on project members rather than project metadata or issues.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing project access), exclusions, or how it relates to other member-related tools (none exist in the sibling list). The agent must infer usage from the purpose alone.

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