Loading ToolBench
MCP server for Jenkins integration with AI assistants, providing build management, log analysis, and failure diagnostics.
Jenkins MCP server has 10 tools with consistent naming (verb-prefixed: trigger, get, async, filter, search, navigate, diagnose) and descriptions present for all tools. However, there are systematic gaps: (1) Output schemas are NOT documented in the provided source, no return type specifications visible for any tool. (2) Parameters lack sufficient constraint documentation (e.g., timeout_seconds has no min/max bounds, poll_interval_seconds lacks range, similarity_threshold has no guidance on 0-1 range despite being stated). (3) Error handling descriptions are missing, tools do not document what happens on failure, retry guidance, or recovery steps. (4) Parameter descriptions are present but generic; many lack actionable format/constraint details. (5) Tool descriptions lack the 'WHEN to use' and 'WHAT it returns' clarity needed for LLM selection. (6) No evidence of idempotency declarations or dry-run support for destructive tools (trigger_build is a WRITE operation). The server uses HTTP+SSE transport and FastMCP framework, which is modern, but tool definitions do not follow production-grade patterns for composition, chaining, and error recovery.
Asynchronously monitors Jenkins build execution with caching and status updates without blocking.
Diagnoses Jenkins build failures by analyzing logs, identifying root causes, suggesting fixes, and providing detailed failure analysis using AI.
Filters and extracts error patterns from Jenkins console logs, identifying common error types, stack traces, and failure indicators.
Fetches the defined parameters (name, type, description, default value) for a Jenkins job. IMPORTANT: jenkins_url is required because jobs are load-balanced across multiple Jenkins servers.
Retrieves console log context around a specific line in a Jenkins build, providing surrounding lines for better understanding of errors or events.
Navigate through Jenkins build logs with intelligent line-by-line retrieval, supporting forward/backward movement and context-aware search.
Output schemas undocumented. No tool provides structured return type definitions. LLMs cannot plan downstream tool calls or know what fields to expect (e.g., does trigger_build return build_number, build_id, status?). This forces agents to guess field names and wastes context on exploratory calls.
Numeric parameters lack range/bounds constraints. timeout_seconds, poll_interval_seconds, line_number, context_lines, max_results, top_k, similarity_threshold, max_depth have no min/max documented. This invites agents to pass absurd values (timeout_seconds=999999, context_lines=-1000) that break APIs or cause timeouts.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
🔎 RIPGREP: Fast pattern search in Jenkins logs with before/after context lines. Supports regex, case-insensitive search, and line number ranges. IMPORTANT: jenkins_url is required because jobs are load-balanced across multiple Jenkins servers.
Semantic search in Jenkins logs using vector embeddings to find contextually relevant log entries, enabling AI-powered log analysis and anomaly detection.
Traverses and analyzes sub-builds (downstream jobs triggered by a parent build) to understand build dependencies and execution flow across multiple jobs.
Triggers a Jenkins build with optional parameters. Supports both synchronous and asynchronous execution modes.
Error handling guidance missing. No tool describes what happens on failure: Is a network error retryable? If a build times out, should the agent retry or ask the user? Tools return 'job not found' but offer no recovery path like 'Try search_jobs() first' or 'Available jobs: job-A, job-B'.
trigger_build (WRITE operation) lacks dry-run or confirmation step. Agents make mistakes, triggering a CI/CD pipeline has irreversible consequences. No mention of idempotency, confirmation_required, or preview mode.
Tool descriptions lack 'WHEN to use' clarity. Many descriptions (e.g., 'Filters and extracts error patterns from Jenkins console logs') are task-level but do not explain when to choose this tool over alternatives, what the agent must provide before calling it, or what the return value enables. LLMs rely on this to disambiguate during tool selection.
Composite operations exposed as single tools. diagnostic_build_failure performs analysis + suggestion generation, combining read + AI reasoning. Similarly, semantic_search couples vector retrieval + embedding inference. These should be split or documented with clear return structures so agents can compose them.
Tool chaining not documented. If get_jenkins_job_parameters returns parameter names and types, does trigger_build's 'parameters' object accept arbitrary keys? If log_context returns line numbers, can ripgrep_search or navigate_log accept them directly as start_line? No documentation of output → input compatibility.
Enum constraints missing. error_patterns (filter_errors), direction (navigate_log: 'forward/backward' should be an enum), similarity_threshold (should have a clear 0.0-1.0 constraint, not just 'number'). Free-form strings invite hallucinated values.