ForLoop MCP provides 13 tools with explicit schemas and descriptions. Naming follows verb_noun convention (list_files, search_code, apply_patch, remember, etc.). All tools have descriptions (10-200 chars, within baseline range). Input schemas use Zod validation with type constraints. However, output schemas are not documented, LLMs cannot predict return structures. Parameter descriptions are present but minimal (e.g., 'Optional limit on number of files to return' lacks context on why/when to use). Error handling is basic: tools delegate to underlying implementations without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, IRREVERSIBLE). Memory tools (remember, search, list, delete) lack documentation of session namespace semantics and data retention. shell.run is high-risk (IRREVERSIBLE) but has no confirmation/dry-run pattern.

• Document output schemas for all 13 tools. Example: 'Returns {files: [{path: string, size: number}], total: number}' for repo.list_files. This enables LLMs to plan downstream calls.
• Add tool annotations to register-tools.ts. Mark shell.run with destructiveHint=true, repo.apply_patch with destructiveHint=true, memory.delete with destructiveHint=true. Use readOnlyHint=true for repo.list_files, repo.search_code, repo.read_file, repo.git_diff, memory.search, memory.list, shell.status.
• Expand memory tool descriptions to clarify scope. Example: 'Store a long-term memory in this MCP session namespace (persisted for the duration of the session, cleared on disconnect). Use tags to organize related memories.'
• Implement confirmation pattern for shell.run. Add a 'dry_run' boolean parameter or require explicit 'confirm=true' flag. Return a preview of what will execute before actually running.
• Enhance parameter descriptions with constraints and context. Example: 'limit: Optional maximum number of files to return (default: 100, max: 10000). Use to avoid overwhelming large codebases.' This matches the 72-char baseline.