Loading ToolBench
Server has 5 tools with mixed quality. Tool naming is inconsistent: redmine_request is a generic wrapper (violates verb_noun pattern), while redmine_paths_list and redmine_paths_info are discovery tools. Descriptions exist but are verbose and include implementation details (YAML string returns) rather than user-facing intent. Input schemas are present but lack enums, ranges, and validation constraints. Critical issue: redmine_request is a pass-through to arbitrary API endpoints with no input validation, rate limiting, or permission gating, this is a security anti-pattern. Output schemas are not documented. Error handling is minimal.
Download an attachment from Redmine and save it to a local file Args: attachment_id: The ID of the attachment to download save_path: Fully qualified path where the file should be saved to (must be within REDMINE_ALLOWED_DIRECTORIES) filename: Optional filename to use for the attachment. If not provided, will be determined from attachment data or URL Returns: str: YAML string containing download status, file path, and any error messages
Get full path information for given path templates Args: path_templates: List of path templates (e.g. ['/issues.json', '/projects.json']) Returns: str: YAML string containing API specifications for the requested paths
Return a list of available API paths from OpenAPI spec Retrieves all endpoint paths defined in the Redmine OpenAPI specification. Remember that you can use the redmine_paths_info tool to get the full specfication for a path. Returns: str: YAML string containing a list of path templates (e.g. '/issues.json')
Make a request to the Redmine API Args: path: API endpoint path (e.g. '/issues.json') method: HTTP method to use (default: 'get') data: Dictionary for request body (for POST/PUT) params: Dictionary for query parameters Returns: str: YAML string containing response status code, body and error message
redmine_request is a generic API pass-through with no input validation, rate limiting, or permission checks. Violates security pattern: agents can invoke arbitrary endpoints, modify any resource, or trigger destructive operations without safeguards.
Tool naming violates verb_noun pattern. 'redmine_request' is generic and does not convey action (get, create, update, delete). LLMs cannot infer intent from the name alone. Should be split into specific tools: get_issue, create_issue, update_issue, etc.
Descriptions include implementation details ('YAML string containing...') instead of user-facing intent. Descriptions should state WHAT the tool does and WHEN to use it, not HOW it returns data. Average description length 52 chars; baseline is 194 chars with context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
Upload a file to Redmine and get a token for attachment Args: file_path: Fully qualified path to the file to upload (must be within REDMINE_ALLOWED_DIRECTORIES) description: Optional description for the file Returns: str: YAML string containing response status code, body and error message The body contains the attachment token
Input schemas lack enums, ranges, and validation constraints. 'method' parameter accepts any string (should be enum: get|post|put|delete|patch). 'path' has no format or pattern. Parameters lack minimum/maximum bounds. Invites invalid LLM input.
Output schemas are not documented. Tools return 'YAML string' but LLMs need to know the structure of that YAML (fields, types, nesting). Without documented output schemas, agents cannot plan downstream calls or extract data reliably.