Loading ToolBench
Local-first Agentic RAG engine - GraphRAG, hybrid retrieval, multi-agent orchestration, MCP-native, 100% local inference.
NexusMind exposes only 2 tools with minimal schema definition and insufficient description quality. The retriever_search tool has a basic schema with 'query' and 'top_k' parameters, but lacks output documentation. The get_ticket_status tool is even more minimal, a single required string parameter with no guidance on ticket ID format or expected output. Both tools lack descriptions meeting the 50-200 char LLM-optimized range (retriever_search is ~110 chars, acceptable; get_ticket_status is ~40 chars, critically short). Parameter descriptions are present but generic. No error handling guidance. Tool composition is simple but not problematic. The tooling infrastructure (mcp/server.py) is functional but exposes limited capabilities and lacks modern MCP patterns.
Fetch the current status of a Jira ticket.
Search the knowledge base using hybrid retrieval (BM25 + dense embeddings with optional reranking)
get_ticket_status description is critically short (40 chars). Provides no context on ticket ID format, expected return fields, or integration prerequisites. LLM cannot determine when to select this tool vs. alternatives.
No output schemas documented for either tool. LLMs cannot plan downstream calls or extract expected fields. retriever_search should document whether results include score, metadata, source. get_ticket_status should document returned fields (status values, timestamp format, etc.).
get_ticket_status parameter 'ticket_id' lacks guidance on format. No description of valid formats (PROJ-123 vs 12345 vs UUID). LLM will guess, causing API errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
retriever_search lacks guidance on query language, result ranking criteria, and reranking conditions. Description mentions 'hybrid retrieval (BM25 + dense embeddings with optional reranking)' but provides no context on when reranking is triggered or how to control it.
No error handling guidance for either tool. retriever_search does not document failure modes (empty results, query parsing failure). get_ticket_status does not document 'ticket not found' or invalid format responses.
retriever_search 'top_k' parameter is unbounded integer with no maximum constraint. LLM could pass excessive values (10000+), causing timeouts or memory exhaustion. Should specify valid range (1-100 recommended).
Tool descriptions do not answer key questions: What does it return? When should the LLM call it instead of alternatives? retriever_search implies knowledge base search, but context (knowledge base contents, update frequency, coverage) is missing. get_ticket_status provides no hint on integration scope (single Jira instance? multiple projects?).