Loading ToolBench
MCP server that provides AI coding assistants with access to LlamaIndex and Chainlit documentation through the Model Context Protocol
VibeUkis MCP exhibits severe quality gaps across naming, descriptions, and schema clarity. While tool names are reasonably action-oriented (how_to_*, read_guide_url), the descriptions are minimal and lack actionable guidance. Most critically, parameter schemas are absent or incomplete, and output schemas are not documented. The server provides 9 tools but only 1 has a visible input schema (read_guide_url with a single 'url' parameter). The remaining 8 tools have descriptions but no parameter details visible in the source code. This violates the hard scoring rule: 'If a tool has NO input schema at all: its schema score MUST be 0.' Only read_guide_url shows an input schema; the other 8 tools appear to have no parameters defined, making them non-interactive lookup tools. Without visible schema definitions in the source, per-tool schema scores default to 0 for 8 of 9 tools.
Get complete Chainlit documentation (call SECOND)
Get complete Firecrawl documentation
Get instructions for using Chainlit (call FIRST)
Get instructions for using Firecrawl documentation
Get instructions for using LlamaIndex (call FIRST)
Get instructions for using Qdrant documentation
Get complete LlamaIndex documentation (call SECOND)
No visible input schemas for 8 of 9 tools. Tools how_to_llamaindex, llamaindex_database, how_to_chainlit, chainlit_database, how_to_firecrawl, firecrawl_database, how_to_qdrant, and qdrant_database show no parameter definitions in src/vibe_ukis/start/mcp.py.
Descriptions are generic and lack actionable guidance. 'Get instructions for using LlamaIndex (call FIRST)' and 'Get complete LlamaIndex documentation (call SECOND)' do not explain what use case each tool serves, when to call it vs. the other, or what the agent can do with the result. Descriptions should be 10 - 1024 chars; these are ~50 - 80 chars but lack specificity per pattern:tool-description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Get complete Qdrant documentation
Fetch and extract content from documentation URLs
No output schema documentation. The server provides 9 tools that return documentation or guide text, but the source code does not specify the structure of return values. Agents cannot plan downstream actions if return format is unknown. Per pattern:tool, 100% of A+ tools have documented return types.
Weak naming distinction between pairs. 'how_to_llamaindex' and 'llamaindex_database' differ only in that one teaches and one is documentation, but the naming does not clearly signal this difference. Similarly, how_to_* vs *_database pairs for chainlit, firecrawl, qdrant are not sufficiently distinct. Per naming pattern, names must make distinctions obvious to avoid LLM conflation.
read_guide_url has minimal description ('Fetch and extract content from documentation URLs') lacking guidance on prerequisites, expected output format, or error cases. Description should explain when to use this (after calling how_to_* or *_database?), what structure is returned (markdown? JSON?), and how to handle failures.
No error handling guidance. The server does not document what happens if a URL is unreachable, content extraction fails, or documentation endpoints are down. Per pattern:recovery-guide, error responses must tell the agent what to do next.