Isolyth provides 4 read-only tools with complete input schemas and descriptions. All tools have clear verb-noun naming (code_exec, db_query, file_ops, web_fetch) and descriptions ranging 120 - 180 chars, meeting baseline minimums. However, parameter descriptions lack detail on constraints, formats, and error recovery. Output schemas are not documented. Error handling is minimal, no guidance on retryability, user-fixable vs fatal errors, or recovery steps. Security is strong (SSRF prevention, sandboxing, read-only enforcement), but descriptions do not highlight these safeguards for LLM awareness.

• Document output schemas for all 4 tools. E.g., code_exec returns {result: number, error?: string}, db_query returns {rows: array, count: number}, file_ops returns {content?: string, files?: array}, web_fetch returns {status: number, body: string, headers: object}.
• Expand parameter descriptions with constraints and examples. E.g., 'expression: A math expression (max 500 chars) using +, -, *, /, ^ (power), %, parentheses, and functions (abs, sqrt, floor, ceil, round, min, max). Example: sqrt(2) * pi. Invalid syntax returns error with position and suggestion.'
• Add error handling guidance to each tool description. E.g., 'db_query: Returns 400 if query contains DDL/DML (INSERT, UPDATE, DELETE, DROP, TRUNCATE). Retry with SELECT only. Returns 500 if database is unavailable, retry after 5 seconds.'
• Describe enum options inline. E.g., file_ops operation: 'read_file (returns file contents as text) or list_directory (returns array of filenames and subdirs in path).'
• Document SSRF and sandbox protections in tool descriptions so LLMs understand security guarantees. E.g., 'web_fetch: Prevents SSRF via DNS validation and IP blocklist. Cannot access private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, ::1).' This builds trust and prevents LLM attempts to bypass controls.

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

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