Loading ToolBench
AI-powered code review and analysis platform exposing codebase mapping, diff analysis, semantic search, git history intelligence, and code review tools via MCP
Argus MCP server defines 5 code analysis tools with good naming (all action verbs: analyze, search, get, find) and moderately detailed descriptions (150-250 chars each). All tools are READ_ONLY and focus on code intelligence. However, schema completeness is mixed: tools have documented input parameters with types and descriptions, but output schemas are NOT visible in the provided source code. Parameter descriptions are present but lack explicit format constraints and examples. Error handling guidance is absent from tool descriptions, LLMs do not know what to do if a git repository is missing, indexing fails, or a search returns no results. The server uses STDIO transport, which is a hard cap at 50 for protocol readiness, but definition quality itself shows competent baseline work with room for improvement in output documentation and error recovery guidance.
Analyze a git diff for bugs, security issues, and code quality problems. Parses the diff, computes risk scores, and returns categorized findings with file/line references. Use this when reviewing code changes or pull requests.
Get git history metrics including temporal coupling between files, ownership analysis, and knowledge silos. Supports analysis types: coupling, ownership, or all.
Find files with high churn and complexity (bug-prone) by analyzing git history. Returns hotspots ranked by change frequency and complexity metrics.
Get a structural overview of the codebase using tree-sitter parsing and PageRank analysis. Returns a token-budgeted map of files and symbols ranked by importance.
Search for code in the repository using hybrid semantic + keyword search. Requires the codebase to be indexed first (will auto-index if no index exists). Use this to find related code, similar patterns, or specific symbols.
Output schemas not documented. Tool descriptions state what they return (e.g., 'returns categorized findings', 'returns hotspots ranked by change frequency'), but the JSON Schema structure of those responses is not visible in the source code. LLMs cannot plan downstream transformations or verify field presence without seeing output schemas.
No error recovery guidance in tool descriptions. If analyze_diff receives invalid unified diff format, search_codebase finds the repo not indexed, or get_history runs on a non-git directory, the descriptions do not tell the LLM how to recover. Missing messages like 'If the codebase is not indexed, this tool will auto-index (may take time)' force the agent to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 24 | 2024-11-05+ | v1 |
Parameter constraints not explicit in descriptions. The 'focus' parameter in analyze_diff documents valid values ('all', 'security', 'bugs', 'style') and 'analysis' in get_history documents values ('coupling', 'ownership', 'all'), but descriptions do not emphasize these are enums or list the complete set of valid values inline. Similarly, 'limit' and 'since_days' parameters lack min/max bounds in descriptions, an LLM could pass limit=999999 or since_days=-100.
Tool composition: No indication of idempotency or caching. If an agent calls search_codebase twice with identical parameters, the tool description does not clarify whether results are cached or re-computed. For tools like get_repo_map that use tree-sitter parsing and PageRank, repeated calls with the same path could be expensive; guidance on idempotency would help agents avoid redundant calls.
Pagination not explicitly mentioned. search_codebase has a 'limit' parameter (default 10) but no explicit mention of how to fetch the next page (offset, cursor, etc.) or whether results are ranked by relevance. For a hybrid semantic+keyword search tool, LLMs need to know pagination strategy to retrieve complete result sets.
Parameter naming ambiguity: 'path' appears in search_codebase, get_repo_map, get_hotspots, and get_history, described as 'Repository path (default: server's configured path)'. An LLM does not know if this is an absolute filesystem path (/home/user/repo), a relative path (./repo), a git remote URL, or a shorthand. The description should clarify: 'Absolute or relative filesystem path to the repository root (e.g., /home/user/project, ../myrepo). Defaults to the server-configured repository path.'
No specification of supported languages. get_repo_map uses tree-sitter parsers for multiple languages (Rust, Python, TypeScript, Go, Java, C, C++, Ruby, PHP, Kotlin, Swift). Tool description does not list which languages are indexed or how the tool handles unsupported languages. An LLM trying to analyze a Clojure codebase will not know it's unsupported until the call fails.