Loading ToolBench
Hybrid dense+sparse search using BGE-M3 embeddings on CPU (ONNX INT8, AVX-512), plus DyTopo multi-agent orchestration with semantic routing. Provides RAG search, indexing, and swarm-based multi-agent reasoning.
This server has significant definition quality issues. While tool names are clear (verb-first), descriptions are verbose and often lack crisp answers to 'what does it do, when should I call it, what does it return'. Parameters have types but descriptions vary in quality and completeness. Output schemas are not explicitly documented in the code visible here. Error handling guidance is absent. The server demonstrates understanding of the domain (RAG, DyTopo swarms) but falls short of production-grade tool engineering standards. Notably, swarm_start has complex nested parameter structures that lack sufficient constraints and validation guidance.
Get per-file metadata including chunk count and SHA256 hash. Useful for tracking file changes and debugging indexing.
Trigger manual re-indexing of RAG documents. Optionally force full re-index even if files haven't changed. Scans configured doc sources, chunks markdown files on ## headers, embeds with BGE-M3, and upserts to Qdrant.
Hybrid semantic+lexical search using BGE-M3 dense vectors (1024-dim) and TF-weighted sparse vectors. Fuses results via Reciprocal Rank Fusion (RRF). Checks LRU embedding cache first for repeated query patterns.
List configured document sources and their file counts. Returns source labels mapped to directory paths with file statistics.
Returns collection info, indexed files, staleness metrics, and chunk counts. Provides diagnostic information about the RAG index state.
Retrieve the final result of a completed DyTopo swarm task. Returns all agent outputs, final topology, execution stats, and quality metrics.
Output schemas not documented in source code. No visible tool return type declarations, field names, or response structures. LLMs cannot plan downstream tool calls or extract data without knowing what fields to expect.
swarm_start parameter structure is deeply nested and under-constrained. The 'agents' parameter is an array of objects with id, role, key, query fields, but no type constraints, enums, or length limits. No guidance on tau range (0.0 - 1.0?), k_in semantics, or rounds upper bound. LLMs cannot validate inputs before invocation.
Error handling and recovery guidance completely absent. No indication of which errors are retryable, which require user intervention, or what to do if a swarm task hangs or fails. Agents have no path forward on errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Launch a DyTopo multi-agent swarm for a task. Initializes agents with semantic routing via MiniLM-L6-v2 descriptors, calls LLM API directly for each agent, and orchestrates message passing based on graph topology.
Check the current progress and status of a running DyTopo swarm. Returns the current round, agent outputs, topology, and any errors.
Descriptions are verbose and bury key information. Example: rag_search description is 249 chars and focuses on implementation details (BGE-M3, RRF, LRU cache) rather than when to call it vs other tools. Should be <100 chars answering: what does it do, when to use it, what does it return.
No output limits or pagination for list-like tools (rag_sources, swarm_result). If a swarm result contains many agent outputs, returning all of it could exhaust context window. No 'limit' or 'offset' parameters, no 'total_count' field documented.
Parameter descriptions are missing or incomplete. 'source' in rag_search says 'Optional document source filter' but does not explain what format the source should be, what happens if the source does not exist, or how to discover valid source values. Agents must guess or call rag_sources first.
No idempotency or confirmation guidance for destructive operations. rag_reindex with force=true can re-process all documents, potentially overwriting indexed state. No dry-run option, no confirmation step, no indication of whether repeated calls are safe.
swarm_start returns a task_id, but tool description does not clarify the semantics: is the swarm executed synchronously or asynchronously? How long does it take? Should the agent immediately call swarm_status or wait? This ambiguity forces trial-and-error.
No chaining metadata. If an agent calls rag_search and then wants to add that document to an index or send it somewhere, the response must include IDs or references the next tool expects. Current descriptions do not document return field names or references.
LLM_BASE_URL and LLM_MODEL are hardcoded in server initialization with no override mechanism exposed to clients. If an agent needs to use a different LLM or endpoint, it cannot. This violates the separation of tool configuration from agent control.