Three tools with basic schemas and minimal descriptions. All tools have input schemas with proper JSON Schema structure (type, properties, required), but descriptions are extremely brief (10-20 chars) and lack context for LLM selection. No output schemas documented. No error recovery guidance. Critically, run_command exposes a DESTRUCTIVE capability without confirmation, dry-run, or permission gates. read_file and write_file lack path validation or sanitization against traversal attacks. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles.

• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it, and what it returns. Example: 'read_file: Read and return the full contents of a file at the given path. Use this to inspect configuration, source code, or data files. Returns file content as plain text. Fails if path does not exist or is not readable.'
• Add path validation: reject paths containing '..', enforce an allowed directory whitelist, and return clear errors like 'Path traversal not allowed. Paths must be within /allowed/dir/'. Sanitize all file paths before passing to fs/promises.
• Add tool annotations: mark read_file with readOnlyHint=true; mark write_file and run_command with destructiveHint=true. This signals to LLMs which tools are safe to retry.
• Implement a confirmation pattern for run_command: add a 'dry_run' boolean parameter (default false). When true, return the command that would execute without running it. Require explicit dry_run=false for actual execution.
• Document output schemas in tool definitions. Add an 'outputSchema' field to each tool listing the response structure (e.g., {type: 'object', properties: {content: {type: 'string'}, error: {type: 'string'}}}). Include this in the ListToolsResponse.

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

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