Loading ToolBench
A knowledge management server that provides semantic search, document management, and container organization for organizing and retrieving information through MCP tools.
Connapse has solid naming conventions and tool-level descriptions, but exhibits significant gaps in parameter-level documentation, output schema clarity, and error handling guidance. All 10 tools are explicitly registered in McpTools.cs with names and descriptions, but parameter descriptions are inconsistent, some parameters like 'json' in bulk_upload and bulk_delete lack actionable format guidance. Output schemas are not documented in the visible code. Error handling returns plain strings without categorization (retryable vs. fatal) or recovery guidance. The server implements tool annotations (ReadOnly, Idempotent, Destructive flags) which is a strength, but lacks structured error classification and output schema documentation required for A-grade quality.
Delete multiple files from a container by their document IDs in a single batch operation.
Upload multiple files to a container in a single batch operation.
Create a new container for organizing documents. Use when setting up a new knowledge domain or project.
Delete a container. It must be emptied first, because deleting one deletes its stored files. External sources are not containers and cannot be deleted here.
Get detailed information about a container including its description, summary, document count, storage size, and status breakdown.
Lists every searchable knowledge scope with its description and document count. Each entry is either kind=managed (storage Connapse owns, browsable with `list_files`) or kind=source (an external system Connapse mirrors read-only — searchable, but it has no file listing). Use to discover what exists when the target is unknown; if the user already named one, call `search_knowledge` on it directly instead.
bulk_upload and bulk_delete 'json' parameter lacks actionable format specification. Description says 'JSON array' but does not document field names, required vs optional fields, encoding format, or provide schema. LLMs cannot reliably construct valid JSON payloads without explicit field-level documentation.
No output schemas documented for any tool. Code returns plain strings (e.g., 'Container created...') but agents cannot programmatically extract structured data (IDs, counts, references) for downstream tool chains. This violates response-shaper pattern and forces LLMs to parse unstructured text.
Error handling returns generic error strings ('Error: Container not found', 'Error: Container already exists') without recovery guidance. Errors do not indicate whether they are retryable or user-fixable, and do not suggest next steps (e.g., 'Try container_list() to see available containers'). Violates recovery-guide pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Get statistical information about a container including document counts, chunk counts, storage usage, embedding model details, and last indexed timestamp.
Delete a single file from a container by its document ID.
Retrieve the full content of a document from a container by document ID or file path.
Search a container using semantic, keyword, or hybrid mode (Hybrid is the default and works well without tuning). Returns ranked passages with citations, scores, and document IDs. If the first query returns thin results, refine the query and call again.
search_knowledge 'mode' parameter lacks enum constraint. Description mentions 'Semantic, Keyword, or Hybrid' but does not enforce them as an enum, allowing LLMs to pass invalid values like 'semantic_only' or 'keyword_and_semantic'. Should declare as enum: ['Semantic', 'Keyword', 'Hybrid'].
Numeric parameters (topK, minScore) in search_knowledge lack explicit range constraints in descriptions. topK description does not state valid range (e.g., 1 - 100); minScore says '0.0-1.0' but no description explains default behavior or validation on the server side.
bulk_upload response does not clearly indicate per-file success/failure. If one file fails out of ten, the agent cannot determine which files succeeded or how to retry. Per-item result tracking is absent.
No dry-run or confirmation step for destructive operations (container_delete, delete_file, bulk_delete). Agents can accidentally delete containers without a safety gate. Confirmation-request pattern not implemented.
container_list and container_describe return unbounded text; no pagination or result limit is enforced. If an org has 10,000 containers, the response could exceed LLM context windows. container_list hardcodes take: int.MaxValue internally, risking token exhaustion.