Semantic code search with precise line-level location results. Indexes codebases for semantic search, keyword search, and code relationship graph queries.
ACI provides well-structured tool definitions with complete input schemas and descriptions for all 7 tools. However, there are significant gaps in output schema documentation, error handling guidance, and response structure that prevent this from being a strong production-grade server. All tools are explicitly registered with proper JSON Schema types and parameter descriptions. The main weaknesses are: (1) no documented output schemas despite complex return types (search results, graph data); (2) missing error handling patterns and recovery guidance; (3) no tool annotations (destructiveHint/readOnlyHint) despite clear risk profiles; (4) parameter descriptions are functional but lack examples of valid values and constraint patterns; (5) no mention of pagination strategy for potentially large result sets.
Get the current status and statistics of the indexed codebase, including total files, chunks, languages, and health information. Optionally specify a path to get stats for a specific repository.
Get structured context for a symbol or file path, including source code, summaries, callers/callees, and graph neighborhood. Returns a rich context package for LLM consumption.
Index a codebase directory for semantic search. This will scan all supported files and create embeddings for code chunks.
List all indexed repositories with their root paths and last update times.
Query the code relationship graph for a symbol or module. Returns callers, callees, dependencies, or dependents with their graph edges.
Search the indexed codebase using semantic search, keyword search, or both. Returns relevant code chunks and summaries with file paths and line numbers. Supports filtering by artifact type to search at different granularity levels.
No output schemas documented for any tool. Complex tools like search_code, get_symbol_context, and query_graph return structured data (code chunks, summaries, graph edges, callers/callees) but the response format is entirely undocumented. LLMs cannot plan downstream calls or extract specific fields without seeing the output structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. index_codebase and update_index modify state (WRITE risk) but have no destructiveHint. search_code, get_index_status, list_indexed_repos, get_symbol_context, query_graph are READ_ONLY but have no readOnlyHint annotation. Agents cannot determine which tools are safe to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Incrementally update the index by detecting new, modified, or deleted files since the last indexing.
Missing error handling patterns and recovery guidance. No documentation of what errors each tool can raise, how to interpret them, or what the agent should do next. For example, search_code might fail due to index not existing, invalid query syntax, or graph lookup failures, but the tool description provides no recovery hints.
No pagination or result-limiting strategy documented for potentially large result sets. search_code accepts 'limit' parameter (capped at 100) but no mention of cursor/offset, total count, or what happens when results exceed limit. list_indexed_repos and query_graph with high depth could return hundreds of items but no pagination guidance.
Parameter descriptions lack actionable constraint examples. 'path' is described as 'Absolute or relative path to the directory' but no examples of valid paths or what happens with symlinks, relative paths from different working directories, or non-existent paths. 'symbol' in get_symbol_context is described as 'fully-qualified symbol name (e.g. ...)' but the example is cut off in the source, and no guidance on resolution order or error cases.
list_indexed_repos has an empty properties object in its input schema, making the parameter documentation impossible to verify. The tool has no required parameters but also no documentation of what fields are returned or the structure of the repo list.
Stateful initialization pattern not visible in code sample. MCP protocol (2026-07-28) emphasizes stateless request handling with _meta context passed per-request. Cannot verify from the provided code whether initialize() is used or if the server is properly stateless.