A code indexing and semantic search server that indexes source code repositories, extracts symbols, embeds them using configurable backends (Ollama, Bedrock, OpenAI, TEI), and provides multi-modal search (keyword + semantic hybrid) via MCP tools.
ctx++ defines 2 tools with reasonable descriptions and basic input schemas. Both tools have descriptive names (ctxpp_index, ctxpp_search) that start with action verbs and clearly indicate their function. Descriptions are present and moderately detailed (168-217 chars, within the 10-1024 char baseline). However, schemas lack completeness: parameters have types and minimal descriptions, but lack critical constraints (enums for 'mode', range/limit specifications for 'limit', format specifications for 'path'). Output schemas are completely undocumented, the LLM has no visibility into what fields to expect from results, breaking the pattern:tool-chain assumption. Error handling is not visible in the provided code. The tools themselves are well-scoped (index vs search), but parameter descriptions are sparse (12-28 chars each), falling below the 72-char baseline for production tools. The 'force' parameter lacks explanation of when/why to use it.
Index or reindex a project codebase. Walks the project root, parses all supported source files, extracts symbols, and stores them in the local index database (.ctxpp/index.db). Subsequent runs are incremental: files whose content has not changed since the last index pass are skipped.
Search the indexed symbols by keyword or semantic similarity. Returns the top-N matching symbols across the project.
Output schemas completely undocumented. LLM has no visibility into result structure, fields, or data types. Breaks tool chaining (pattern:tool-chain), agent cannot plan downstream calls.
Parameter descriptions are too sparse. 'path' (12 chars), 'force' (5 chars), 'query' (26 chars), 'mode' (35 chars), 'limit' (35 chars) are all well below the 72-char baseline. LLMs cannot infer when to use 'force', what exact query syntax is expected, or what the search result limit actually caps.
'mode' parameter in ctxpp_search accepts enum ['keyword', 'semantic', 'hybrid'] but description does not explain the difference between modes or when to use each. LLM cannot reason about mode selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
'limit' parameter lacks numeric constraints (min/max). No documentation of default (10 is stated but not enforced). Unbounded parameters invite LLMs to pass absurd values.
No error handling guidance visible in tool definitions. If index fails, search returns no results, or path is invalid, the LLM has no recovery path. Breaks pattern:recovery-guide.
'path' parameter default behavior is unclear in the tool definition (docs say 'default: $CTXPP_PROJECT or current directory' but schema does not enforce this). LLM may pass empty string expecting fallback, with undefined results.