MCP server that exposes code search functionality via ripgrep pattern matching and semantic embedding-based similarity search across configured file indexes and git repositories
The Regen MCP server defines 2 tools with complete JSON Schema input schemas and actionable descriptions. Both tools are well-named with clear verb-noun structure (ripgrep_search, embedding_search). Descriptions are concise and contextually useful (91-128 chars, within the 10-1024 guideline). However, several gaps limit production readiness: output schemas are completely undocumented, LLMs cannot plan downstream tool calls without knowing what fields to expect; parameter descriptions lack critical detail about constraints (e.g., ripgrep_search.maxResults has no explanation of why 100 is the default or whether higher values are unsafe); error handling is absent, no guidance on what happens when a search fails, whether retries are safe, or how LLMs should recover; no mention of pagination for embedding_search despite potentially large result sets; no tool annotations (readOnlyHint, idempotentHint) to clarify safety and idempotency. The schema structures for both tools are valid JSON Schema with proper types and required fields, preventing catastrophic misuse, but lack depth. Overall composition is reasonable: tools are single-responsibility and follow the search-centric domain, though no tool chaining guidance is visible.
Semantic similarity search using AI embeddings across all configured indexes
Search files using ripgrep across all configured indexes
Output schemas completely undocumented. LLMs cannot determine what fields ripgrep_search and embedding_search return, blocking downstream tool planning and forcing guesswork about available data.
Parameter descriptions lack actionable constraints. 'maxResults' defaults to 100 or 10 but no explanation of why, whether higher values are unsafe, or if pagination is needed for larger result sets. 'model' enum is not explained, LLMs must guess what embeddinggemma-300M-Q8_0 means.
No error handling guidance. If a search fails (invalid pattern, unsupported embedding model, no results), the tool provides no recovery guidance. LLMs cannot distinguish retryable errors from user-fixable ones.
No tool annotations. Both tools are read-only and idempotent, but lack explicit readOnlyHint and idempotentHint declarations. LLMs cannot confirm safety and may incorrectly assume retry risks.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
embedding_search 'extensions' parameter is poorly described. It accepts an array of file extensions but lacks examples, constraints, or explanation of how it combines with the task type (RetrievalQuery vs SemanticSimilarity).
No pagination support documented. ripgrep_search caps maxResults at 100 and embedding_search at 10, but no mention of how to retrieve next batch or total count. Large codebases may hit these limits without clear recovery path.