Loading ToolBench
Production-grade MCP (Model Context Protocol) and A2A (Agent-to-Agent) servers in Go with multi-tenant RAG pipeline, JWT authentication, cost tracking, and distributed tracing
This MCP server has moderate structural quality but significant gaps in schema visibility and description rigor. The server exposes 7 tools across search, retrieval, and analysis domains. Tool names follow verb-noun conventions (search, retrieve, list, analyze, summarize) which is positive. However, critical issues emerge: (1) Input schemas are partially visible in the provided source, we can see parameter names and basic types for most tools, but validation rules, constraints, and complete schema declarations are not fully evident in the code samples provided. (2) Descriptions are present but generic; most are 50-100 characters and lack actionable guidance on when to use each tool vs. alternatives (e.g., 'search' vs 'hybrid_search' distinction is unclear from descriptions alone). (3) No output schemas are documented in the visible code. (4) Error handling is mentioned as a feature (errorReporting=true) but no recovery guidance or error categorization is visible in the tool definitions. (5) No tool annotations (readonly/destructive hints) are evident despite all tools being READ_ONLY, which should be explicitly declared. The code shows telemetry and observability infrastructure (OpenTelemetry, Prometheus) but tool-level quality metrics are not apparent.
Analyze source code for patterns and issues
Perform hybrid search combining BM25 full-text search with vector semantic search
List all available documents with optional filtering
Retrieve a specific document by ID from the database
Search documents and papers using BM25 full-text search
Search academic papers and research documents
Generate concise summaries of research documents
Output schemas not documented. No visible return type declarations for any tool. LLMs cannot reason about result structure or chain tool calls without knowing what fields are returned.
Tool descriptions lack actionable guidance. 'Search documents and papers using BM25 full-text search' does not explain when to use this over hybrid_search, what query format is expected, or what the results contain. Descriptions should be 50-200 characters and answer: what, when, why.
No input validation constraints visible in schemas. Parameters like 'limit' and 'max_results' have defaults but no stated min/max bounds. Unbounded integers let LLMs pass absurd values (e.g., limit=999999).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | 2024-11-05+ | v1 |
No tool annotations despite all tools being READ_ONLY. Tool definitions should include readOnlyHint=true to signal to clients that these operations are safe to retry and do not modify state. Current MCP spec supports tool annotations.
Ambiguous tool naming and overlapping responsibilities. Three search variants exist (search, hybrid_search, search_papers) with minimal differentiation in descriptions. LLMs will struggle to pick the right one. Clarify: search = BM25 only on general docs, hybrid_search = BM25+vector on docs, search_papers = specialized academic search.
Error handling guidance not visible. While errorReporting=true is declared, no tool description indicates what errors are possible, when they are retryable, or what the LLM should do if a search returns 0 results or a document retrieval fails.
Parameter 'language' in analyze_code lacks enum constraint. Free-form string invites hallucinated values like 'python3' or 'py' instead of canonical 'python'. Should declare: enum=['python', 'javascript', 'go', 'rust', 'java', ...].
Missing parameter descriptions. 'document' in summarize_document is vague, is it a document ID, raw text, file path, or URL? Description must clarify expected format.