Loading ToolBench
MCP-native AI Agent Framework — plug any MCP server, ship an agent in minutes
OmniBot exposes 9 tools via HTTP/FastAPI, but critical definition gaps severely limit production readiness. Tool names lack action verbs and are overly generic (e.g., 'chat', 'root', 'health'). Descriptions exist but are minimal (10-50 chars for most) and fail to guide LLM selection. Most critically, input schemas lack detail: parameters are documented but JSON Schema type definitions are incomplete or missing. No error recovery guidance, no output schema documentation, and no per-parameter constraints. The server is architecturally sound (FastAPI, async) but the tool interface is underdeveloped for agentic use.
Chat endpoint supporting both regular and non-streaming responses.
Streaming chat endpoint. Returns Server-Sent Events (SSE) with step-by-step agent execution events.
Health check endpoint.
Get knowledge base statistics.
List all available tools (MCP + built-in).
Health check and server status endpoint.
Run the agent with full control and step-by-step results.
Critical naming violations: 6 of 9 tools do not start with action verbs. 'root', 'health', 'websocket_chat', 'chat', 'chat_stream' violate verb_noun convention. LLMs cannot infer intent from names alone.
Descriptions are uniformly under 70 characters and lack selection guidance. None explain WHEN to use each tool vs similar tools (e.g., chat vs chat_stream vs run_agent). No 'If you need X, call this' guidance.
Parameter type definitions are incomplete or absent in visible code. 'file' in upload_knowledge lacks type (string? binary?). 'conversation' in run_agent is array but item type is not specified. LLMs cannot validate inputs without explicit types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Upload a document (PDF/TXT/MD) to the knowledge base.
WebSocket chat endpoint with agent support and session management.
No output schemas documented. Tools return AgentResponse, BotResponse, ToolInfo, etc., but response field types and nested structures are not formally declared in tool definitions. Agents cannot plan downstream calls without knowing what fields to expect.
Duplicate and conflicting tools: both 'chat' and 'run_agent' appear to do agent message handling. Both 'root' and 'health' perform status checks. No clear distinction or deprecation guidance. LLMs will waste reasoning cycles deciding between them.
No error recovery guidance. Tools return errors but do not tell LLMs what to do next (retry, ask user, try alternative tool). 'Invalid file format' does not guide the agent to retry with PDF.
Missing parameter descriptions in endpoint handlers. Input schemas for chat, chat_stream lack in-code descriptions for 'channel', 'text', 'session_id'. Parameter 'file' in upload_knowledge lacks encoding/format details.
websocket_chat tool definition appears only as a router reference; actual tool registration is not visible in provided code. Tool may be inferred rather than explicitly defined, limiting verifiability.