JARVIS exposes 34 tools with minimal schema documentation. Most tools lack visible input parameter schemas in the provided source code. Descriptions are present but generic (10-50 chars typical). No parameter type definitions, constraints, or output schemas documented. Tool names use inconsistent prefixes (mcp__jarvis__ vs bare names like WebSearch). Critical security issues: run_command and open_in_terminal are IRREVERSIBLE with no confirmation patterns. No error handling guidance visible. This server would require substantial refactoring to meet production quality standards.

• Add complete JSON Schema input definitions for all 34 tools. Include type, description, enum constraints, and min/max for every parameter. Example: {"url": {"type": "string", "description": "Full HTTP(S) URL to open (e.g., https://example.com)", "pattern": "^https?://"}}
• Expand descriptions to 100-200 chars. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) what it returns, (4) any prerequisites. Example: 'List all active Claude Code sessions with their IDs, status, and creation time. Use this first to discover available sessions before calling session_detail or steer_session.'
• Rename tools to remove 'mcp__jarvis__' prefix. Use verb_noun pattern: list_sessions, get_session_detail, steer_session. Keep names under 25 chars. Consistency aids LLM tool selection.
• Add confirmation/dry-run pattern for irreversible tools (run_command, open_in_terminal). Require explicit confirmation parameter or return a 'confirm_required' response with details before executing. Prevents accidental destructive actions.
• Document output schemas for all tools. Specify returned fields, types, pagination (limit/offset/total_count), and chaining IDs. Example: {"sessions": [{"id": "string", "status": "enum[active|paused|completed]", "created_at": "ISO8601"}], "total": "integer"}

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

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