Loading ToolBench
Server has 5 tools with complete schemas and basic descriptions, but quality is inconsistent. All tools have input schemas with type definitions and descriptions present. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool or what happens on failure. No output schemas documented. Parameter descriptions are present but terse. Error handling is absent, generic 'Failed to make TestRail request' provides no recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Naming follows verb_noun convention (get_, add_, delete_, update_) which is good, but descriptions do not explain dependencies or side effects. This is typical C-grade community server work.
Adds new TestRail project
Deletes a TestRail project
Returns given TestRail project.
Returns the list of available TestRail projects.
Updates a TestRail project
Descriptions are too brief (10-50 chars) and lack context. 'Adds new TestRail project' does not explain when to use this vs update-project, what happens on failure, or prerequisites. LLMs cannot reliably select the right tool.
No output schemas documented. Callers cannot know what fields to expect from responses. This forces LLMs to guess at response structure and breaks tool chaining.
Error handling is generic and non-actionable. 'Failed to make TestRail request: {statusText}' gives no recovery guidance. LLMs cannot determine if the error is retryable, user-fixable, or fatal.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without reading descriptions. delete-project and update-project should be marked destructive.
get-projects lacks pagination documentation. No mention of result limits, whether results are capped, or how to fetch beyond the default 250. Large result sets risk context window exhaustion.