RepoYeti MCP server demonstrates solid definition quality with well-structured tool naming following verb_noun conventions and comprehensive parameter documentation. All 16 tools have explicit schemas with typed parameters and descriptions. However, several tools lack sufficient context in their descriptions to guide LLM selection, and output schemas are not documented in the provided code. The server excels at accepting human-friendly identifiers (repo id, name, or basename) and clearly marking which tools are mutative. Error handling guidance is minimal, descriptions state WHAT happens but rarely explain recovery paths or when to use one tool vs another.

• Add explicit output schema documentation for every tool. Specify return type (object/array), required/optional fields, and field types. Example: 'Returns: array of {id: string, name: string, branch: string, dirty: boolean, ahead: number, behind: number}'.
• Enhance descriptions with dependency hints and recovery guidance. E.g., 'git_diff: Show uncommitted changes in one file. Call repo_changes first to list changed paths. Returns an error if the path is not modified; LLMs should re-run repo_changes to confirm the path.'
• Document pagination for multi-item tools. E.g., 'git_log: List commits (max 50 per call). Accepts limit (1 - 100) and uses offset for pagination. Returns total_count so LLMs know when more results exist.'
• Add max result limits to tool descriptions. E.g., 'list_repos returns up to 100 repos; use filtering or pagination for larger collections.'
• For mutative tools, add error classification in descriptions: 'git_commit errors: no changes (retry with repo_changes), unresolved conflicts (manual intervention needed), permission denied (check repository access).'
• Provide confirmation or dry-run guidance for destructive operations. E.g., 'collaboration_commit_sync: Requires 10-minute unchanged state observation and explicit MCP approval. Call collaboration_status first to confirm eligibility.'
• Clarify 'drift', specify if it returns a list of repo summaries or an aggregate count, and suggest follow-up tools (e.g., 'Use repo_status on drifted repos to see exact ahead/behind counts').