RepoMapper demonstrates solid tool design with 12 well-named, verb-prefixed tools (repomapper_*) covering code intelligence tasks. All tools have descriptions (avg ~120 chars) and explicit input schemas using Zod. However, output schemas are not documented in the visible code, and several parameter descriptions lack actionable detail (e.g., 'Max results, default 100' without explaining what constitutes a 'result'). Error handling is minimal, no recovery guidance or categorization visible. Tool composition is strong: each tool has a single responsibility, and chaining is supported via consistent path/file parameters. Security is appropriate for a read-only local tool.

• Document output schemas for all tools. Use Zod or JSON Schema to define return types (e.g., repomapper_grep returns {path: string, line: number, content: string}[]). Include this in tool registration or a separate schema reference.
• Add explicit min/max bounds to numeric parameters. E.g., depth: z.number().int().min(1).max(20), limit: z.number().int().min(1).max(1000). Update descriptions to state these bounds: 'Max depth (1 - 20, default 3)'.
• Implement error responses with recovery guidance. When a file is not found, return {error: 'File not found', suggestion: 'Try repomapper_search() to locate the file'}. Categorize errors as retryable vs. user-fixable.
• Add total count or next_cursor to paginated results. E.g., repomapper_imports should return {imports: [...], total: 42, hasMore: true} so LLMs know whether to fetch the next page.
• Standardize descriptions to English only. Remove Chinese translations from tool and parameter descriptions to improve LLM parsing consistency and reduce token overhead.