Server has 9 tools with basic schemas and descriptions, but significant quality gaps. Most tool descriptions are under 50 chars (well below the 194-char baseline for A+ tools). Parameter descriptions are minimal or absent. No output schemas documented. No error handling guidance. Tool naming is acceptable (verb_noun pattern), but descriptions lack context on WHEN to use each tool and what to expect. The 'TestMcp' tool is a placeholder with no clear purpose. No pagination support despite list_jobs and get_last_builds returning potentially large result sets. Schemas present but sparse, most parameters lack detailed constraints or format guidance.

• Expand tool descriptions to 100 - 200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. E.g., 'List all Jenkins jobs in the current instance. Use this to discover available jobs before triggering builds or fetching job details. Returns a list of job objects with name, url, and color fields.'
• Document output schemas for all tools. Specify field names, types, and structure. E.g., list_jobs returns [{name: string, url: string, color: string, ...}]. This enables LLMs to plan downstream calls and extract data correctly.
• Add pagination to list_jobs: accept limit (default 20, max 100) and offset parameters. Return total_count and next_offset. Cap results at 50 items by default to prevent context window exhaustion.
• Add parameter descriptions for all inputs. E.g., job_name: 'The name of the Jenkins job (case-sensitive, e.g. "my-build-job")'. Include format hints and constraints in descriptions since LLMs do not parse JSON Schema patterns.
• Remove or replace TestMcp. If a diagnostic tool is needed, rename it to 'test_jenkins_connection' and document what it validates (e.g., 'Verify Jenkins server is reachable and credentials are valid').

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

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