Server Quality Checklist

Tool Scores

• redmine_paths_infoB
  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 the full burden. It discloses the return format (YAML string) but does not explicitly state that it is a read-only operation or that it has no side effects. The verb 'Get' implies a read, but safety is not confirmed. Additionally, there is no mention of error behavior or authorization requirements, which is needed for a 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.

  Conciseness4/5

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

  The description is appropriately sized and uses a clear docstring structure with Args and Returns sections. It is front-loaded with the core purpose and concise, without redundant information. It could be even more compact but is not verbose.

  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 an output schema (not shown) and a description that explains the return type (YAML string). For a single-parameter introspection tool, it covers the essentials. However, it lacks guidance on when to use it relative to siblings (e.g., redmine_request) and does not explain the relationship between path templates and actual paths, which could be important for correct invocation. It is adequate but not complete.

  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 schema has 0% description coverage, so the description must compensate. It does so by specifying that path_templates is a 'List of path templates' and provides clear examples (['/issues.json', '/projects.json']). This gives the agent a concrete sense of expected input. However, it does not define what 'path templates' means (e.g., if wildcards are allowed) or clarify constraints, leaving some ambiguity, but overall it is effective.

  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: 'Get full path information for given path templates'. It uses a specific verb ('Get') and resource ('path information'), and the returning YAML string of API specifications distinguishes it from siblings like redmine_request (which makes requests) and redmine_paths_list (which lists paths). The purpose is unambiguous and differentiates 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?

  There is no explicit guidance on when to use this tool instead of siblings. While one can infer it is for retrieving API specs for path templates, it does not mention alternatives or exclusions. For example, it does not say 'Use this before making a request with redmine_request' or 'Consider redmine_paths_list for available paths.' This leaves the agent to guess.

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

• redmine_requestA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It notes that the method can be 'get', 'post', 'put', etc., implying potential write side effects, but it does not disclose authentication requirements, rate limits, or that responses are returned as a YAML string. The phrase 'error message' in the return hints at error handling but is insufficient for a generic tool that could perform destructive writes without explicit warning.

  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 compact docstring with a one-line purpose, an Args section, and a Returns section. Every sentence serves a purpose, and the most important information (the purpose) is front-loaded. No fluff or repetition.

  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 that this is a low-level API client, the description covers the essential aspects: how to call it (path, method, data, params) and what it returns (YAML with status, body, error). However, it omits critical operational context such as authentication handling, rate limits, and any warnings about using methods other than GET. Since an output schema exists (though not shown), the return format is partially covered, but the lack of security or safety notes is a gap.

  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 description coverage is 0%, so the description is the sole source of parameter meaning. It precisely defines each parameter: 'path' as an API endpoint path with an example, 'method' as HTTP method with a default, 'data' as request body for POST/PUT, and 'params' as query parameters. This far exceeds the schema, which only lists types and 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 states 'Make a request to the Redmine API', which clearly identifies the tool's purpose as a generic HTTP client for Redmine. It is distinct from the sibling tools (redmine_paths_list, redmine_paths_info, redmine_upload, redmine_download) which are higher-level specific operations. The verb 'make' and resource 'Redmine API' are explicit and unambiguous.

  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 gives no guidance on when to use this tool versus the sibling tools. There is no mention of using it only for endpoints not covered by specific helpers, nor any exclusions or alternatives. The agent would have to infer that this is the low-level fallback, but the description doesn't state that explicitly.

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

• redmine_uploadA
  4.1/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 disclosure burden, and it does so well: it reveals the return envelope (YAML with status code, body, error message), the location of the attachment token, and the critical security boundary (file must be within REDMINE_ALLOWED_DIRECTORIES). It stops short of covering auth requirements, persistence side-effects, or rate limits, but the non-obvious details it does disclose are genuinely useful.

  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?

  Purpose is front-loaded in one line, followed by a tight Args block and a Returns block. No wasted phrasing; the Returns explanation of the YAML envelope carries real behavioral value rather than padding. Structure is clean and scannable, with only the verbosity of the YAML explanation being slightly expandable.

  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?

  An output schema exists, so return values are already covered, yet the description still adds the envelope context. For a moderate-complexity mutation tool, it covers purpose, both parameters, the security constraint, and return format. It's largely complete; only auth/permission prerequisites and side-effect persistence notes are absent, which are minor against the output schema coverage.

  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 description coverage is 0%, so the description must compensate, and it does: file_path gains the essential allowed-directories constraint, and description is clarified as optional. Both parameters receive meaning beyond the bare schema titles ('File Path', 'Description'). Only minor gaps remain, such as description length limits or path format examples.

  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?

  States a specific verb and resource ('Upload a file to Redmine') plus a concrete outcome ('get a token for attachment'). This immediately distinguishes it from sibling redmine_download (inverse operation) and redmine_paths_* (path lookups). The purpose is unambiguous and non-tautological.

  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 intent is implied by the purpose — uploading a file to obtain an attachment token for later use — and the security constraint hints at context, but there is no explicit when-to-use vs when-not-to-use guidance or reference to siblings like redmine_request for non-file operations. Usage context is present but left to inference.

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

• redmine_paths_listA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. For a zero-parameter read-only list operation there is little to disclose, and the description does disclose the return format (YAML string of path templates), which is the main behavioral trait. It does not contradict any annotations since none exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

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

  The description is reasonably efficient but has redundancy: 'Return a list of available API paths' and 'Retrieves all endpoint paths' say the same thing twice. It also contains a typo ('specfication'). The structure is otherwise front-loaded with the core purpose, and the Returns note is useful.

  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 zero-parameter enumeration tool this is complete: it states the purpose, the output type, and cross-references the sibling tool for further depth. An output schema exists, so return-value details need no further elaboration. Minor blemishes (typo, mild redundancy) don't materially reduce usefulness.

  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?

  With zero parameters the description has nothing to document, and the baseline for a no-parameter tool is 4. The description need not elaborate further; its only param-adjacent content (that it takes no input) is implicit in the empty 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 states a specific verb+resource: 'Return a list of available API paths from OpenAPI spec.' It clearly distinguishes itself from siblings by being the enumeration tool, while explicitly noting that redmine_paths_info provides the full spec for a single path. The example ('/issues.json') further grounds what a path template looks like.

  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 names the sibling alternative (redmine_paths_info) and explains when it applies ('to get the full specification for a path'), giving an agent a clear decision point between listing all paths and drilling into one. It stops short of a full when-to-use/when-not-to-use directive, so it isn't a 5.

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

• redmine_downloadA
  4.5/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 mentions the save_path must be within REDMINE_ALLOWED_DIRECTORIES, the optional filename behavior, and that returns are a YAML string with status, file path, and errors. These go beyond the obvious and materially help an agent anticipate side effects and 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?

  The description is efficiently structured: a one-sentence summary, then Args list, then Returns. No redundant text, and the key purpose is front-loaded. Each line earns its place.

  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 download tool with three parameters (one optional) and no annotations, the description covers the essentials: directory restriction, optional filename nuance, and return format. It does not mention overwrite behavior or specific failure modes beyond generic error messages, but given the output schema exists, these are minor gaps.

  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 description coverage is 0%, yet the description fully compensates. Each parameter is explained: attachment_id (the ID), save_path (fully qualified file path with a directory restriction), and filename (optional, for the download URL, not affecting save path). This adds meaning well beyond the schema's bare titles.

  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 opening sentence states the exact action: 'Download an attachment from Redmine and save it to a local file.' This clearly identifies the verb (download), resource (attachment), and destination (local file). It effectively distinguishes from siblings like redmine_upload and redmine_request.

  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 its use case by specifying it downloads attachments and saves locally. While it does not explicitly mention alternatives or when not to use it, the purpose is so unambiguous that an agent would not confuse it with siblings. No exclusions are stated, but the context is clear.

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