The server has 6 tools with mostly clear names and basic descriptions, but critical gaps in parameter documentation and output schema specification prevent a higher score. Tool names follow verb_noun pattern well (list_jobs, search_jobs, get_job_info, list_builds, get_build_status, trigger_build). Descriptions are present but lack depth, they state WHAT the tool does but not WHEN to use it or what structures are returned. Parameter schemas use Zod for basic type validation, but descriptions are often minimal (e.g., 'The name of the Jenkins job' lacks clarity about naming conventions or case sensitivity). Most tools lack documented output schemas, responses are constructed as ad-hoc text blocks rather than structured payloads. Error handling returns isError flags but lacks actionable recovery guidance. The trigger_build tool has a concerning design: it accepts a 'confirmed' parameter defaulting to false, which partially mitigates risk but forces the agent to make two calls (one dry-run, one confirmed), wasting tokens.

• Add explicit output schema definitions for every tool. Example for list_jobs: return {jobs: [{name: string, url: string, status: 'blue'|'red'|'yellow', lastBuild?: {number: number, timestamp: string}}], total: number}. Document this in JSDoc or in the tool registration.
• Expand parameter descriptions to include constraints. For jobName: 'The exact name of the Jenkins job (case-sensitive, URL-encoded if contains spaces). E.g., "my-deployment-job" or "backend%20tests".'
• Implement pagination for list_jobs and list_builds. Add 'offset' and 'total_count' to responses. Cap default limit at 20 and max limit at 100 to prevent runaway calls.
• Replace trigger_build's 'confirmed' parameter with a dry-run capability. Return a summary of what would be triggered, then require agent to explicitly request trigger with a separate call or a confirmation token.
• Add recovery guidance to error responses. Example: if get_job_info returns 404, respond: 'Job "backend-test" not found. Try search_jobs(pattern="backend") to see available jobs.' This lets LLM self-correct.
• Enhance tool descriptions with decision-making context. For get_job_info vs. list_builds: 'Call get_job_info to see job configuration, parameters, and last 3 build summaries. Call list_builds to retrieve a paginated list of all recent builds with timestamps and results.'
• Add tool annotations (readOnlyHint, destructiveHint) in tool registration. Mark list_*, get_*, search_* with readOnlyHint=true. Mark trigger_build with destructiveHint=true so the client can warn the agent.