Mini-Gravity has 11 tools with significant quality gaps. Most descriptions are present but lack LLM-optimized structure (many exceed 200 chars, some contain French text inconsistently). Input schemas exist for all tools but lack proper type definitions and constraints. No enum constraints on categorical parameters (e.g., 'command' in run_shell_command). Parameter descriptions are minimal (avg ~40 chars vs baseline 72). No output schemas documented. Error handling is absent, tools provide no recovery guidance. Tool naming is reasonable (verb-noun pattern) but some names are ambiguous ('ingest_file' vs 'scrape_and_learn' overlap in intent). Critical security issue: run_shell_command and start_background_process expose dangerous operations without permission gates or dry-run patterns. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels assigned.

• Add output schemas to all tools. Document return types, field names, and structure. E.g., search_web should return {results: [{url: string, summary: string, relevance: number}], total_count: number}.
• Implement permission gates and dry-run patterns for destructive tools. run_shell_command should validate against a whitelist of safe commands (ls, cat, pip install, mkdir only). start_background_process should require explicit approval or return a confirmation step.
• Expand parameter descriptions to 50-150 chars with format/constraint guidance. E.g., 'command: Shell command to execute. Allowed: ls, cat, pip install, mkdir. Avoid: rm, sudo, server start commands.'
• Add enum constraints to categorical parameters. E.g., run_shell_command.command could accept predefined safe commands; search_knowledge.query could have max_length=500.
• Expose tool annotations via readOnlyHint, destructiveHint, and idempotentHint in tool definitions. Mark write_file and run_shell_command as destructiveHint=true; mark read_file as readOnlyHint=true.