This MCP server exposes 3 tools with significant quality gaps. Tool definitions are visible in main.py with basic descriptions, but parameter documentation is minimal, output schemas are undocumented, and error handling guidance is absent. The shell_command tool is particularly risky (DESTRUCTIVE risk level) with no confirmation pattern or permission checks. Web tools lack pagination, result limits, and structured output schemas. Descriptions are present but generic (10-50 chars each), and parameter types are inferred from Python type hints rather than explicitly documented in descriptions. No per-parameter descriptions are visible for most inputs. Output behavior is unspecified. This is typical of a community-grade server that works but lacks production-hardening.

• Add confirmation/dry-run pattern to shell_command. Example: add optional 'dry_run' boolean param; if true, return what would execute without actually running. This prevents catastrophic errors from agent misuse.
• Document output schema for all tools. Specify fields, types, and nesting. Example for web_search: {"results": [{"title": string, "url": string, "snippet": string}], "result_count": number, "next_cursor": string?}. This enables tool chaining and structured parsing.
• Expand tool descriptions to 80-150 chars. Example for shell_command: 'Execute a shell command and return output. Use for system tasks (file operations, package management). SECURITY: User commands are NOT validated, use only for trusted inputs. Returns stdout/stderr and exit code. Max execution time: 30 seconds.'
• Implement result limits and pagination for web_scrape and web_search. Add 'limit' param (default 20, max 100) and 'offset' or 'cursor' param. Always return total count. Example: web_search(query, limit=20, offset=0) -> {results: [...], total: 1523, next_offset: 20}.
• Add per-parameter descriptions in tool docstrings. Example: search_type param: 'Mode of search: "question" for factual Q&A (e.g., "What is X?"), "context" for background info (e.g., "Tell me about X"), None for standard web search.'
• Implement structured error responses with recovery guidance. Example: 'URL invalid: must start with http:// or https://. Got: "example.com". Did you mean: https://example.com?'. Classify errors (retryable, user-fixable, fatal) so LLM knows next step.

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

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