Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. fs.readText and fs.list have minimal descriptions (under 100 chars). process.run lacks critical safety documentation around command injection and timeout behavior. No output schemas documented. Parameter descriptions exist but are sparse. No error recovery guidance. Tool naming follows verb_noun convention (positive), but descriptions do not explain WHEN to use each tool or what happens on failure.

• Add output schemas for all three tools. Document what fields are returned (e.g., fs.readText returns {content: string, encoding: string}, fs.list returns {entries: [{name: string, type: 'file'|'dir'}], total: number}).
• Expand tool descriptions to 150-250 chars. For fs.readText: 'Read text file content within project boundary. Use to inspect source code, config files, or documentation. Returns file content as string. Fails if path is outside project root or file is binary.'
• Add explicit security guidance to process.run: 'Executes shell commands. CRITICAL: Always pass arguments via args array, never concatenate into command string. Prevents command injection. Supports timeout to prevent hung processes.'
• Document error conditions and recovery for each tool. E.g., 'If path not found, check available files with fs.list(). If permission denied, verify project boundary configuration.'
• Add constraints to process.run timeout: specify the server max (e.g., 'timeoutMs: max 30000ms') and explain what happens on timeout (process killed, error returned).

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

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