Server has 5 well-named tools with clear verb-noun patterns (list_, get_, search_). All tools have descriptions (avg 85 chars, within baseline 34-392). Input schemas are present with typed parameters and descriptions. However, output schemas are NOT documented, critical gap for LLM planning. Parameter descriptions lack format constraints (e.g., 'repo' format, 'limit' bounds). No error handling guidance or recovery paths. Security is strong (read-only, input validation, log redaction), but missing tool annotations (readOnlyHint) and pagination metadata (total_count, next_cursor). Composition is clean, each tool has one responsibility.

• Document output schema for each tool. Example for list_workflow_runs: 'Returns {runs: [{id, name, status, conclusion, created_at, updated_at}], total_count: int, next_cursor?: string}'. This enables LLMs to chain calls and extract run_id for get_workflow_run.
• Add pagination metadata. list_workflow_runs and list_run_jobs should return total_count and next_cursor. Cap results at 20-50 items per call (currently no cap visible). Document limit bounds in parameter descriptions (e.g., 'limit: 1-100, default 20').
• Convert status/conclusion parameters to enums. Instead of free-form strings, define: status: enum['queued', 'in_progress', 'completed'] and conclusion: enum['success', 'failure', 'cancelled', 'skipped']. This prevents hallucinated values.
• Add error recovery guidance. Wrap API calls with try-catch that returns actionable messages: 'Repository not found. Verify owner/name format (e.g., microsoft/vscode).' or 'GitHub API rate limit exceeded. Retry after 60 seconds.' Pattern: recovery-guide.
• Declare tool annotations. Register each tool with readOnlyHint=true in FastMCP tool definition. This signals to agents that these tools are safe to call without confirmation. Aligns with current spec (2026-07-28).

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

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