Server exposes 48 tools across filesystem, git, network, shell, postgres, and system domains. Critical gaps: most tools lack visible input schemas in source (only traceroute shows explicit schema). Descriptions are present but generic (10-50 chars typical). No parameter descriptions visible. Error handling is basic. Tool names follow verb_noun convention (readFile, gitStatus, httpRequest) but lack specificity for disambiguation. No tool annotations (readOnlyHint, destructiveHint) despite high-risk operations (deletePath, killProcess, runCommand). Output schemas undocumented. This is a broad-capability server with poor LLM-readiness, agents will struggle to understand when/how to use tools.

• Extract and document input schemas for all 48 tools. Use Zod or JSON Schema to define parameter types, constraints (enums, min/max), and descriptions. Baseline: 4 params per tool, all with type + description.
• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'Read file contents. Use before editing to check current state. Returns text or binary data depending on file type.'
• Add tool annotations: mark destructive tools (deletePath, killProcess, runCommand) with destructiveHint=true; mark read-only tools with readOnlyHint=true; mark idempotent tools with idempotentHint=true.
• Implement dry-run or confirmation pattern for irreversible operations. Add optional 'confirm' parameter or separate 'preview_*' tools (e.g., preview_delete_path) so agents can verify before executing.
• Document output schemas for each tool. Specify returned fields, types, and pagination (if applicable). Include IDs/references needed for downstream tool calls (e.g., if gitLog returns commit_id, gitShow should accept it).

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

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