Loading ToolBench
Semantic code search MCP server for repositories. Provides semantic search over codebases, index status reporting, and reindexing capabilities.
Akin exposes 3 well-named, semantically clear tools with comprehensive descriptions and properly typed input schemas. akin_search is exceptionally documented with usage guidance and scoping advice. All tools have descriptions >100 chars and parameters include type, description, and defaults. However, output schemas are not formally documented, responses are returned as plain strings (FormatResult wraps CommandResult into text), forcing LLMs to parse unstructured output. No error handling guidance, no recovery hints, and no structured response schema definition. Tool composition is sound (each does one thing), but lack of output documentation and error classification prevents A-grade scoring.
Forces a full rebuild of the Akin index for this repository. Use this when the index appears stale or incomplete. Reindexing a small-to-medium repository typically takes a few seconds.
Semantic code search over the current repository. Returns ranked files with line ranges and optional code snippets. Best for discovery — finding files when you don't yet know the vocabulary the codebase uses (e.g. "how do we handle backwards compatibility", "where do we deal with rate limiting", "what's our pattern for background jobs"). Use grep instead when the concept has a unique greppable marker — an attribute name, a distinctive identifier, an exact error string — since grep is faster and more precise when you already know what to search for. Combine with grep for completeness. Semantic ranking has silent recall gaps: a relevant file may be missing from the results without any indication. Treat akin's output as a starting set, not exhaustive. A common workflow is akin first to learn the vocabulary the codebase uses (attribute names, doc-comment phrasing, type names), then grep on those terms to enumerate every occurrence. Expect some noise in broad queries — generated files or large schemas can rank alongside genuine matches; scope with paths/excludePaths/includeTypes when possible. Defaults are tuned for broad surveys: paths and line ranges only (no snippet text), capped at 3 regions per file (overflow rendered as "+N more matches not shown"). For focused follow-ups, pass includeSnippets=true to get the chunk text inline. Raise maxRegionsPerFile when you genuinely need every match in a file, or set it to 1 for the most compact "one representative match per file" survey. Scope further with paths/excludePaths (glob patterns) and/or includeTypes (file categories: "code", "docs", "config").
Reports the current state of the Akin index for this repository: whether it is ready, how many files and chunks are stored, and whether it is compatible with the current embedding/chunker configuration.
Output schemas not documented. All tools return plain strings (FormatResult concatenates Message + Details). LLMs cannot parse structured results or extract fields for downstream tool calls. Responses should be JSON objects with typed fields (e.g., {status: 'ready', fileCount: int, chunkCount: int}).
No error handling guidance. Tools return CommandResult but do not document what errors are possible, whether they are retryable, or what the LLM should do next. E.g., if reindex fails due to lock contention, should the agent retry? Wait? Fail?
akin_search returns results as text with line ranges and optional snippets, but no structured list of file objects. LLMs cannot reliably extract file paths, line numbers, or snippet text for follow-up actions. Should return {files: [{path, lineStart, lineEnd, snippet?, score}], totalMatches, overflow}.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
akin_reindex has no dry-run or confirmation step. Reindexing is a write operation that rebuilds the entire index, agents should confirm before executing. Consider adding a 'confirm' parameter or a separate 'preview_reindex' tool.
akin_search parameter 'maxResults' and 'maxRegionsPerFile' lack explicit min/max bounds in schema. Description says 'Default 10' and 'Must be at least 1', but JSON Schema should enforce {minimum: 1, maximum: 100} to prevent LLM from passing absurd values.