Claustrum defines 2 tools with minimal structure. Both tools accept function parameters ('execute', 'preview') that cannot be serialized to JSON Schema, these are JavaScript functions, not data. Input schemas are declared as generic 'object' type with no property definitions, violating JSON Schema best practices. Descriptions exist but are vague and do not explain WHEN to use each tool or what the LLM should expect. No output schema is documented. The 'read' tool description ('Register a read-only tool...') describes the registration API, not the tool's behavior from the agent's perspective. No error handling guidance. Tool names ('read', 'propose') are generic and do not follow verb_noun convention.

• Replace function parameters with JSON-serializable data. Instead of passing 'execute' as a function, define the tool's actual behavior in the description and accept input parameters that the server-side implementation will process.
• Document output schemas explicitly. For 'read' tools, specify: {type: 'object', properties: {result: {type: 'string'}, status: {type: 'string'}}}. For 'propose' tools, specify: {type: 'object', properties: {proposal_id: {type: 'string'}, status: {type: 'string'}}}.
• Rename tools to follow verb_noun convention: 'read' → 'execute_read_tool', 'propose' → 'execute_destructive_tool' or use domain-specific names like 'preview_changes' and 'apply_changes'.
• Rewrite descriptions from the agent's perspective. E.g., 'read': 'Execute a read-only operation immediately. Use this for queries that do not modify state.' 'propose': 'Submit a destructive operation for human review. Returns a proposal ID to poll for approval status.'
• Add error handling guidance: 'If the tool fails, the error will include a reason code (permission_denied, invalid_input, timeout) and recovery steps. Retry only if reason is timeout.'