Loading ToolBench
MCP Server for semantic code search across company codebase libraries. Searches shared repositories using semantic similarity to find reusable implementations and design patterns.
Two tools with adequate naming but inconsistent schema documentation and descriptions. search_code has good naming and a complete input schema with type constraints, but lacks documented output schema structure. get_stats has minimal description (29 chars) and an empty parameter object with no constraints. Both tools lack explicit error handling guidance and recovery documentation. Schema visibility is partial, input schemas are declared, but output shapes are not documented in the source, forcing LLMs to infer structure from usage context.
Get a summary of what's in the team's shared codebase library — how many functions are indexed, which repositories, languages, design patterns, and frameworks are represented. Use this to understand what's available before searching, or when the user asks about the team's tech stack or codebase composition.
Search the team's shared codebase library for reusable implementations and patterns. This searches ACROSS MULTIPLE REPOSITORIES (not the current project) using semantic similarity. Returns full source code of matching functions with design pattern and framework annotations. WHEN TO USE: 1. BEFORE writing new code for common concerns — authentication, telemetry/observability, logging, database access, error handling, API clients, middleware, configuration, caching, retry logic, circuit breakers, rate limiting, validation. The team likely has existing implementations and preferred libraries. Search first, then generate code that follows the team's established patterns. 2. When the user asks conceptual questions like 'how do we handle X', 'show me examples of Y', 'what patterns do we use for Z'. 3. When you're about to recommend a third-party library — check if the team already has an internal wrapper or preferred alternative. WHEN NOT TO USE: - Finding specific symbols, files, or definitions in the CURRENT project (use Grep/Glob/Read). - Exact function name lookups like 'findUserById' (use Grep). - Reading or modifying files in the current working directory.
get_stats has a trivial description (29 characters) that provides no guidance on when to call it or what it returns. This tool barely justifies its existence in the description.
Output schemas are not documented in the source code. search_code returns semantic matches and full source code, but LLMs have no schema to understand the response structure (e.g., does it return {matches: [{code, pattern, framework}]} or a flat list?). get_stats returns 'summary' but field names and types are not visible. LLMs need to know what fields to expect.'
No error handling guidance. Neither tool's description explains what happens on failure (e.g., vector DB offline, no matches found, invalid query).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
search_code's 'query' parameter lacks format constraints. The description recommends 'conceptual' queries but does not formally forbid exact function names or file paths. LLMs will still try 'findUserById' (the tool explicitly warns against this) because there's no enum or pattern constraint.
Pagination missing from search_code despite potentially returning large result sets. The 'limit' parameter caps results but there's no offset, cursor, or total_count in the documented schema. If the vector DB has 10,000 indexed functions, LLMs cannot iterate through results.
get_stats's empty parameters object and vague description do not explain what 'summary' contains. Does it return {repositories: [], languages: [], patterns: [], frameworks: []}? Does it include counts? Field names are unstated. LLMs cannot plan downstream steps without knowing the response structure.