The Jenkins MCP server has 15 tools with explicitly defined schemas and descriptions in src/tools/definitions.ts. However, the definitions exhibit significant gaps that limit production readiness. Tool names follow verb_noun conventions (good), but descriptions are inconsistent in depth. Most critically: (1) Parameter descriptions are sparse or absent, many parameters lack guidance on valid values, formats, or constraints; (2) Output schemas are not documented, callers cannot predict the structure of responses; (3) No error recovery guidance is provided, tools do not tell LLMs what to do when calls fail; (4) Enums are underutilized, free-form string parameters like 'classPattern', 'fullNamePattern', and 'colorPattern' invite hallucinated regex values instead of bounded options. For example, 'query_items' accepts three regex parameters with no description of the syntax, valid patterns, or examples. The tool would benefit from constraining searches to predefined filters or providing explicit format guidance. Tools like 'build_item' accept optional 'parameters' as a free-form object with no schema or documentation of what keys are valid. Overall, the server demonstrates basic competency but lacks the depth expected of production-grade tools.

• Document the output schema for every tool. For example, 'get_item' should specify: returns {fullName: string, description: string, class: string, lastBuild?: {number: number, url: string}, ...}. This enables LLM reasoning about downstream tool calls.
• Add detailed parameter descriptions for 'query_items'. Specify: 'classPattern is a Java regex (case-sensitive) to match Jenkins item class names, e.g., "^hudson\\.model\\..*Job$" for all job types. If omitted, no class filter is applied.'
• Convert 'build_item' parameters from free-form to a documented schema or enum. Either: (a) list valid parameter keys with their types (e.g., {BUILD_VAR: string, TIMEOUT_MINUTES: number}), or (b) provide examples and a constraint that parameters must match the job definition.
• Add error recovery guidance to tool descriptions. E.g., 'build_item: If the response indicates "Job already building", the job is busy, wait or call get_build to monitor progress. If "Job not found", call get_all_items or query_items to locate the correct full name.'
• Implement pagination for list-returning tools (get_all_items, get_all_nodes, get_all_queue_items). Add optional parameters: limit (default 20, max 100), offset (default 0). Return {items: [...], total: number, hasMore: boolean} so the LLM can iterate efficiently.
• Add enum constraints to parameters where Jenkins enforces a fixed set of values. E.g., if Jenkins build statuses are BLUE, RED, YELLOW, DISABLED, create a colorPattern parameter with enum: ['BLUE', 'RED', 'YELLOW', 'DISABLED'] instead of free-form regex.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry