Loading ToolBench
MCP server scaffold to monitor and react to Drone CI pipelines.
This server has 11 tools with basic structure but significant gaps. Most tools have descriptions (ranging 34 - 120 chars, within baseline 34 - 392), but parameter descriptions are inconsistent and often missing depth. Input schemas are present and declare types, but lack validation constraints (enums, min/max). Output schemas are partially documented in TypeScript interfaces (visible in read-only-tools.ts for ListBuildsOutput, GetBuildOutput, etc.) but are not exposed in the tool registration itself. No tool annotations (readOnlyHint/destructiveHint) despite clear risk divisions. Error handling is minimal, no recovery guidance or categorization. Naming is clear and verb-prefixed (get_, list_, restart_, stop_, approve_, decline_) but lacks dependencies/prerequisites documentation. The server includes a dryRun pattern for write operations (pattern:confirmation-request), which is excellent for agent safety, but this is not documented in tool descriptions. Overall, the server is functional but mediocre, typical of mid-tier community servers.
Approve one gated build in Drone.
Decline one gated build in Drone.
Get one build details by build number.
Get logs for one build stage/step.
Get cached build state snapshot by build number.
List all active (pending, running, blocked) builds from the build state store.
List builds for a repository.
Output schemas not exposed in tool registration, interfaces defined in .ts files (ListReposOutput, ListBuildsOutput, etc.) but not returned/documented in McpToolDefinition. LLM cannot infer response structure from tool metadata.
Write tools (drone_restart_build, drone_stop_build, drone_approve_build, drone_decline_build) lack detailed descriptions of side effects and irreversibility. Descriptions are generic ('Restart one build in Drone'). No mention of dryRun parameter benefit or idempotency guarantees.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in tool definitions. Server clearly divides read-only (7 tools) and write (4 tools) but LLM has no machine-readable signal. Must infer from description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
List repositories visible to the Drone token.
Minimal diagnostic tool for MCP client compatibility checks.
Restart one build in Drone.
Stop one running build in Drone.
Numeric parameters (page, limit, buildNumber, stageNumber, stepNumber, limitChars) lack min/max constraints in schema. e.g., limitChars says 'max 100000' in description but no JSON Schema maxLength/maximum constraint. LLM cannot validate before calling.
Filter parameters in drone_list_builds (prNumber, sourceBranch, targetBranch) documented as 'optional' but no guidance on how they interact with pagination or data completeness. FILTER_SCAN_LIMIT_WARNING exists in code but only returned in ListBuildsOutput, not in tool description.
Error handling absent. Tools call client methods (restartBuild, stopBuild, etc.) but source does not show try/catch or error classification. If API fails, agent receives raw exception with no recovery guidance.
drone_get_cached_build_state and drone_list_active_builds lack description context: When should agent call these vs. the API versions? What is the cache age? What happens if cache is stale? These are discovery/decision tools but description does not explain use case.
Pagination guidance missing. drone_list_repos and drone_list_builds accept page/limit but description does not state default page size, max limit, or whether cursor-based pagination is available. LLM must guess optimal pagination strategy.