Loading ToolBench
Global MCP Server for Documentation Search across registered workspaces with integrated indexing, search, and embedding capabilities
The server defines 6 tools with mixed quality. Naming is acceptable (verb_noun pattern), and descriptions exist for all tools. However, schema completeness is inconsistent: search_workspaces and get_file_content have well-defined input schemas with proper types and descriptions, but critical gaps appear in parameter documentation, output schemas are entirely undocumented, and error handling lacks recovery guidance. The most significant issue is the absence of output schema documentation across all tools, LLMs cannot plan downstream tool chains without knowing what fields to expect. Additionally, parameter relationships (e.g., how 'search_type' filters results) and constraints (e.g., valid 'search_type' values) are under-specified. The tool descriptions are solid (80-160 chars, exceeding the 10-char minimum) and serve their purpose, but parameter-level descriptions, while present, often lack actionable constraint information.
Get content from a specific file with metadata and outline for better AI context. Supports line range selection and provides file outline/structure information.
Get optimized context for a query by combining search results with intelligent formatting and token management for LLM consumption.
Get detailed information about a specific workspace including statistics about indexed files, documents, code symbols, and embeddings.
Initialize or update indexing for a workspace. Triggers full indexing, parsing, and embedding generation for the specified path.
List all registered workspaces with their metadata including names, paths, and descriptions.
Search across registered workspaces for documentation and code. This tool works best with SHORT, KEYWORD-BASED queries (2-4 key terms). Supports searching by workspace, filtering by content type (code, docs, config, all), and limiting results.
No output schema documentation for any tool. LLMs cannot determine what fields to expect in responses, preventing downstream tool composition and forcing agents to guess at field names.
search_type parameter lacks enum constraint. Description states 'all', 'code', 'docs', 'config' as options, but schema does not enforce this as an enum. LLMs may pass invalid values.
No error handling guidance in any tool description. If search_workspaces fails (workspace not found, registry unavailable), the description does not explain what to do next or what errors are possible.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
index_workspace is marked WRITE but has no confirmation step or dry-run mode. Agents could accidentally re-index large workspaces with force=true, wasting compute and time.
Parameter constraints are incomplete. max_results defaults to 10 and max_tokens defaults to 4000, but min/max bounds are not stated. No constraints on query length or workspace_id format.
get_file_content parameters start_line and end_line lack validation rules. Can LLMs pass negative numbers? What happens if start_line > end_line? These ambiguities invite invalid calls.
Tool chain references are broken. If search_workspaces returns file paths, agents will need to call get_file_content next. But search result structure is undocumented, so agents cannot extract the correct file_path format.