Local-first code intelligence for coding agents — 9 tools for go-to-definition, find-references, call/type hierarchy, and semantic search computed locally from your own repositories
This MCP server has critical definition quality issues. All 9 tools are documented ONLY in an Astro marketing website (ToolShowcase.astro) and shell scripts, NOT in the MCP server source code itself. No tool schemas, input parameters, or output types are visible in any server implementation file. The server command is 'jarvis-server' but no actual server code is provided, only documentation site files and shell hooks. Tool descriptions exist in the website but lack the technical depth required for agent integration: no input schemas, no parameter types, no output structure documentation, no error handling guidance. This violates the core MCP pattern that tool definitions must be machine-readable and schema-validated.
Tools (9)
blastRadiusread onlysource verified32/100
2-hop bounded BFS over the package dependency graph to scope change impact.
callHierarchyread onlysource verified35/100
Walk callers and callees of a function — single-level, bidirectional.
documentSymbolsread onlysource verified35/100
List every top-level symbol defined in a file with its range.
findReferencesread onlysource verified38/100
List every occurrence of a symbol across the codebase, definition included.
getIndexStatusread onlysource verified37/100
Check whether a repo is indexed, how fresh it is, and which capabilities are available.
goToDefinitionread onlysource verified37/100
Jump to where a symbol is defined — resolved via SCIP's precise AST.
searchCoderead onlysource verified35/100
Lexical search via an embedded Zoekt index — fast, precise, always available.
NO VISIBLE INPUT SCHEMAS for any tool. All 9 tools have schema score 0 because source code contains no JSON Schema definitions, parameter types, or property constraints.
Tool descriptions exist only in website HTML (ToolShowcase.astro), not in server code. No machine-readable tool registration visible. Descriptions are 15-70 characters, many under the 20-char floor, and lack parameter documentation, output schema, error handling, or usage context.
CREATE a TypeScript/Node.js MCP server implementation with explicit tool registration. Define all 9 tools using JSON Schema input/output schemas. The current repository appears to be documentation only; no actual server code is visible.
ADD COMPLETE INPUT SCHEMAS for every tool. Example for goToDefinition: { symbol: {type: 'string', description: 'Fully-qualified symbol name (e.g., io.Reader.Read)'}, file?: {type: 'string', description: 'Optional file path to restrict search scope'}, repository: {type: 'string', description: 'Repository identifier or path'} }
DOCUMENT OUTPUT SCHEMAS with explicit return types. Example for goToDefinition: { location: {type: 'object', properties: {file: {type: 'string'}, line: {type: 'number'}, column: {type: 'number'}, endLine: {type: 'number'}, endColumn: {type: 'number'}}}, symbol: {type: 'string'}, context: {type: 'string', description: '2-3 lines of code around the definition'} }
ADD PER-PARAMETER DESCRIPTIONS. Every parameter must explain: (1) what it controls, (2) expected format/type, (3) required or optional, (4) constraints or allowed values. Current names alone are ambiguous to LLMs.
EXPAND TOOL DESCRIPTIONS to 100-150 characters minimum. State WHAT the tool does, WHEN to call it vs similar tools, WHAT it returns, and any PREREQUISITES. Current descriptions (15-70 chars) are marketing copy, not agent-usable guidance.
DOCUMENT ERROR HANDLING explicitly. Define error codes/scenarios: 'Index not found' (retryable, suggest getIndexStatus), 'Symbol not found in indexed codebase' (user-fixable, suggest searchCode), 'Semantic search unavailable' (fatal unless [semantic] is installed). Provide recovery guidance for each.
Score history
Overall score trend
First recorded score · v2 rubric
35/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
35
2026-07-28+
v2
semanticSearchread onlysource verified40/100
Natural-language code search powered by embeddings.
typeHierarchyread onlysource verified38/100
Single-level super/subtypes for a symbol within a repo.
NO PARAMETER DOCUMENTATION. Tools like 'goToDefinition' and 'findReferences' clearly need inputs (symbol name, file path, repository identifier) but source code shows no parameter definitions, types, or descriptions.
NO OUTPUT SCHEMA DOCUMENTATION. Tools return complex results (symbol definitions with line ranges, call graphs, search results) but no return type, field names, structure, or pagination guidance is visible in server code.
NO ERROR HANDLING GUIDANCE. No visible error codes, retry logic, recovery suggestions, or classification (retryable vs fatal). Shell hook shows 'Hook errors' but no tool error handling in server code.
TOOL DEFINITIONS INFERRED, NOT EXPLICIT. Tools exist only as marketing copy in Astro components. No TypeScript server implementation visible. Per HARD SCORING RULE, tool definitions inferred rather than explicitly registered in source code are capped at 50.
MISSING PREREQUISITE DOCUMENTATION. Tools like 'semanticSearch' and 'typeHierarchy' require special indexing ('requires [semantic] extra + reindex', 'requires fork-built scip') but no input parameter documents this, agents won't know when to call what.
semanticSearchtypeHierarchy
ADD PAGINATION for tools returning multiple results (findReferences, searchCode, blastRadius, callHierarchy). Include limit, offset, total_count in both input schema and output response. Cap default to 20-50 items.
MIGRATE from Astro documentation site to server-side tool registry. The MCP server must advertise tools via the tools list in the ListTools response, with full JSON Schema, not via HTML.
ADD TOOL ANNOTATIONS (readOnlyHint, idempotentHint) per MCP spec 2026-07-28. All 9 tools are READ_ONLY; annotate them: { tools: [{name: 'getIndexStatus', inputSchema: {...}, annotations: {readOnlyHint: true}}] }
DOCUMENT COMPOSITION: which tools chain together? E.g., 'Use goToDefinition to jump to a symbol, then findReferences to see all callers.' Without this, agents don't know the intended workflow.
VALIDATE INPUTS inside each tool. Return structured error messages: 'Invalid repository path. Must be an absolute path or git remote URL. Got: invalid-path'. Do not expose raw exceptions.
DOCUMENT CAPABILITY DEPENDENCIES in tool descriptions. E.g., semanticSearch: 'Requires semantic search index enabled. Call getIndexStatus first to verify indexing status and available capabilities.'