MCP server for exploring Git history with semantic search using SQLite and local embeddings
Spelungit defines 5 tools with moderate quality. All tools have descriptions and basic input schemas with type definitions, placing them in the mediocre-to-fair range. Naming is clear and verb-based (index_, search_, get_, list_). However, multiple critical issues prevent a higher score: (1) Parameter descriptions are minimal or missing detail about constraints and formats. (2) Output schemas are completely undocumented, there is no visible response schema for any tool, forcing LLMs to infer output structure. (3) Error handling is not evident in the visible code, no recovery guidance, no error categorization, no actionable error messages shown. (4) The 'repository_path' parameter is widely used but lacks guidance on absolute vs relative paths, validation rules, or examples. (5) The 'limit' parameter in search_commits has no min/max bounds specified. Naming and descriptions are present, so the server avoids an F grade, but the absence of documented response schemas and sparse parameter validation keeps it in the C/D range.
Get detailed information about a specific commit including diff, author, timestamp, and full commit message.
Get the current indexing status of a repository including progress for ongoing operations.
Index a Git repository for semantic search. Analyzes all commits and creates embeddings for full-text and semantic search capabilities.
List all indexed Git repositories with their indexing status and statistics.
Search Git commits using semantic search. Finds commits semantically similar to the query using embeddings.
No output/response schemas documented for any tool. LLMs cannot infer the structure of commit details, search results, or repository status. Agents must guess what fields are available, risking failed downstream tool calls.
'limit' parameter in search_commits has no min/max bounds. Unbounded numeric parameters allow LLMs to pass absurd values (limit=999999) causing timeouts or resource exhaustion.
Parameter descriptions are sparse and lack actionable constraints. 'repository_path' is used in 4 tools but has no guidance on absolute vs relative paths, validation rules, or error handling for missing paths. 'commit_sha' has no format specification (40 hex chars? short form?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Error handling and recovery guidance are not visible in tool implementations or descriptions. No evidence of error categorization (retryable vs user-fixable vs fatal), no guidance on what to do if a repository is not found, no timeout handling for indexing operations.
list_repositories lacks pagination parameters (limit, offset/cursor). If many repositories are indexed, returning all results will blow the context window. No guidance on result limits.
search_commits description mentions 'optional path to specific repository' but no guidance on how the tool behaves if omitted (searches all? searches default?). Undocumented optional behavior creates ambiguity for LLM invocation.