The server defines 15 tools with consistent verb_noun naming (container_list, image_inspect, etc.) and all have brief descriptions. However, most descriptions are extremely short (8 - 25 chars), leaving LLMs with minimal context about WHEN to use each tool or WHAT it returns. Input schemas are present and mostly well-typed, but output schemas are not documented in the provided source. Parameter descriptions are present but terse. Error handling, recovery guidance, and composition support are not evident from the code. The server covers a focused domain (Podman container/image/network/volume operations) competently but with gaps in description depth and output documentation that prevent higher scoring.

• Expand tool descriptions from 8 - 25 chars to 60 - 150 chars. Answer: WHAT does it do? WHEN is it useful? WHAT structure is returned? Example: 'List all containers. Use this to discover container IDs before calling inspect or start. Returns array of container metadata with id, name, status, image.',
• Document output schemas for every tool in pkg/mcp/tools.go. For each tool, add a 'Returns' or 'Output' comment block with field names, types, and meanings. Example: 'Returns: {containers: [{id: string, name: string, status: string, image: string, created: RFC3339, memory_usage_mb: number}], total_count: number}'
• Add pagination to list tools. Accept optional 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return 'total_count' and 'has_more' fields so the LLM can iterate without loading all results at once.
• Implement error recovery guidance. In each tool's error path, return structured error responses: {error: string, error_code: string, recovery_hint: string}. Example: 'Container not found. Call container_list to see available containers.' or 'Remove failed: container is running. Call container_stop first or pass force=true.'
• Add a 'dry_run' parameter to destructive tools (container_remove, image_remove). When true, validate the operation but do not execute. Return what would be deleted so the LLM can confirm.
• Expand container_logs description to explain stdout/stderr/follow/timestamps behavior. Example: 'Stream or retrieve container logs. stdout=true includes standard output; stderr=true includes error output. follow=true streams new logs in real-time (may block). timestamps=true prepends RFC3339 timestamps. tail limits to the last N lines (e.g., tail="100").'

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained