Summary
The MCP tool descriptions document language support inconsistently. references / callers / callees (McpToolDefinitions.cs:70-132) name a specific list of supported languages in prose; unused_symbols and symbol_hotspots (McpToolDefinitions.cs:314) mention "supported languages" without enumerating them; other tools say nothing. An agent reading the catalog cannot tell whether requesting --lang dart for callers is supported, unsupported-but-silently-empty, or unsupported-with-error — they must trial-and-error. Each tool needs a single authoritative language-support clause.
Where
src/CodeIndex/Mcp/McpToolDefinitions.cs:70-132 (references/callers/callees)src/CodeIndex/Mcp/McpToolDefinitions.cs:314 (unused_symbols / symbol_hotspots)
Suggested approach
(1) Introduce a single SupportedLanguages static (sourced from the same registry that --list-langs uses) and have each tool definition either reference the canonical list or enumerate the subset it supports inline. (2) Standardise the prose: "Supports: C#, TypeScript, JavaScript, Python, Go, Rust, Java, PHP, Ruby, Bash, SQL, Dockerfile, ..." in the same order and wording across tools. (3) For tools that support a subset of the registry (e.g. unused-symbol detection only works for languages whose extractor emits definition+references), make the subset explicit. (4) When a client supplies an unsupported --lang, return a structured error with supported_languages: [...] rather than an empty result. (5) Mirror the consistency in README.md "Language support" and DEVELOPER_GUIDE.md. (6) Add a regression test that loads the tool catalog and asserts every tool's description matches the registry it claims.
Summary
The MCP tool descriptions document language support inconsistently.
references/callers/callees(McpToolDefinitions.cs:70-132) name a specific list of supported languages in prose;unused_symbolsandsymbol_hotspots(McpToolDefinitions.cs:314) mention "supported languages" without enumerating them; other tools say nothing. An agent reading the catalog cannot tell whether requesting--lang dartforcallersis supported, unsupported-but-silently-empty, or unsupported-with-error — they must trial-and-error. Each tool needs a single authoritative language-support clause.Where
src/CodeIndex/Mcp/McpToolDefinitions.cs:70-132(references/callers/callees)src/CodeIndex/Mcp/McpToolDefinitions.cs:314(unused_symbols / symbol_hotspots)Suggested approach
(1) Introduce a single
SupportedLanguagesstatic (sourced from the same registry that--list-langsuses) and have each tool definition either reference the canonical list or enumerate the subset it supports inline. (2) Standardise the prose: "Supports: C#, TypeScript, JavaScript, Python, Go, Rust, Java, PHP, Ruby, Bash, SQL, Dockerfile, ..." in the same order and wording across tools. (3) For tools that support a subset of the registry (e.g. unused-symbol detection only works for languages whose extractor emits definition+references), make the subset explicit. (4) When a client supplies an unsupported--lang, return a structured error withsupported_languages: [...]rather than an empty result. (5) Mirror the consistency inREADME.md"Language support" andDEVELOPER_GUIDE.md. (6) Add a regression test that loads the tool catalog and asserts every tool's description matches the registry it claims.