Loading ToolBench
A Model Context Protocol server for Retrieval-Augmented Generation (RAG) with multi-knowledge-base support, hybrid search (BM25 + vector), and sequential indexing orchestration.
FieldCure MCP RAG demonstrates solid tool design with clear naming conventions (verb_noun pattern), comprehensive descriptions (avg 180 chars, within 10-1024 baseline), and well-structured input schemas. All 7 tools have explicit descriptions and typed parameters. Tool annotations (ReadOnly, Destructive, Idempotent) are present and correct. Error handling includes structured JSON responses with actionable error messages. Key gaps: output schemas are not formally documented in the source; parameter descriptions lack explicit format/constraint details (e.g., top_k range, threshold bounds); no pagination support despite search_documents returning ranked results; missing recovery guidance in error responses.
Removes a pending indexing request from the queue. No-op if the entry is already running or does not exist. Cannot cancel an in-progress run — use the cancel file mechanism for that.
Compares source files on disk against the index to detect added, modified, and deleted files. Does not modify the index. Lightweight metadata-only operation (no GPU, no API calls). Use before start_reindex to determine if re-indexing is needed. Also detects DB schema staleness and contextualization degradation.
Retrieves the full content of a specific chunk by its ID. Use after search_documents to get complete text of a result.
Returns index metadata for a knowledge base: file/chunk counts, indexing status, prompt hash for stale-index detection, and queue state (position, deferred, last_error). Use after start_reindex to poll for progress. The queue field shows pending/running/failed status.
Lists all available knowledge bases with their status. Returns ID, name, file/chunk counts, indexing status, and schema version for each KB. A KB with is_schema_stale=true still serves search queries correctly; re-indexing triggers automatic schema migration through the exec path.
Output schemas not formally documented. Tools return JSON but no schema definitions visible in source code. LLMs cannot reliably parse responses or plan downstream calls without knowing field names and types.
search_documents lacks pagination parameters (limit, offset, next_cursor). Description mentions 'top_k' but no explicit bounds documented (e.g., 'max 100'). Large result sets risk context window exhaustion.
Parameter constraints not explicit in descriptions. 'top_k' (integer), 'threshold' (float 0-1), and 'search_mode' (enum) lack min/max bounds and valid value lists in parameter descriptions. LLMs cannot validate inputs without formal constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Searches documents in a knowledge base using hybrid BM25 keyword + vector semantic search. Returns ranked results with source file and content preview.
Queues an indexing request for the specified knowledge base. All requests are processed sequentially by a background orchestrator to avoid GPU contention — the request may not start immediately if another KB is currently indexing. Use check_changes first to determine if re-indexing is needed. Use get_index_info to poll for progress after queuing. Do not call this unless the user explicitly asks for indexing or a scheduled task requires it.
Error responses lack recovery guidance. CancelReindexTool returns reason codes ('already_running', 'not_found') but does not suggest next steps. CheckChangesTool catches exceptions but error message does not guide LLM on retry strategy.
Tool composition assumes sequential workflow (check_changes → start_reindex → get_index_info) but no single tool wraps this pattern. Agents must chain 3 calls for a common operation, wasting tokens and inviting mid-chain failures.