Loading ToolBench
A sovereign logic engine web application built with the Kitwork framework, providing routes for database operations, QR code generation, rendering, caching, background tasks, and HTTP requests
This server exhibits pervasive, critical gaps across naming, descriptions, schemas, and error handling. The codebase shows HTTP endpoints exposed as MCP 'tools', but with minimal formalization of tool contracts. Of 21 claimed tools, most lack explicit input schemas, parameter descriptions, and output documentation. Many tools have trivial or missing descriptions (e.g., 'Serve favicon file', 'Serve static assets'). Parameter types are either missing or inferred from context rather than formally declared. Error handling is absent in most tools. The few tools with parameters (e.g., /qrcode/napas, /screenshot) provide loose descriptions without enum constraints, format specifications, or validation guidance. The server appears to be a Kitwork demo/starter application, not a production-grade MCP server. No tool follows the verb_noun naming convention. Security and permission checks are absent. Composition patterns are ignored, tools like /db/write combine create, update, and delete into one endpoint rather than separate, composable operations.
Catch-all route that renders pages based on request path
API root endpoint returning hello message from HUB
Fetch and return gold price data with 5 second cache, mapping buy and sell prices
Test cache endpoint with 1 hour cache duration
Serve static assets from assets directory
Start a background task that runs asynchronously and returns immediately
Start a background task that fetches users from database asynchronously
Render dashboard page
CRITICAL: No tool follows verb_noun naming convention. Names are HTTP paths (GET /favicon.ico, GET /assets/*) rather than action-oriented identifiers (serve_favicon, serve_asset, read_from_database). LLMs cannot infer intent from raw HTTP endpoints.
CRITICAL: 19 of 21 tools have NO visible input schema. Tools with parameters (path, site, id, bank, account, amount, desc, url) lack JSON Schema type definitions, required/optional markers, or constraints. For example, /qrcode/napas accepts 4 string parameters with zero schema structure or validation guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
Perform database read operations including find, first, list, exists, and count queries
Perform database write operations including create, update, and delete
Render documentation page with optional site parameter
Serve favicon file from assets
Return hello world text response
Generate Napas QR code from query parameters (bank, account, amount, desc)
Capture screenshot of a webpage using chromedp
Serve Tailwind CSS JavaScript file
Generate automatic Napas-like QR code in SVG format with gradient styling
Generate VietQR payment QR code in PNG format with VietinBank account details and amount
Generate VietQR payment QR code in SVG format with complex gradient styling for three finder positions
Generate WiFi configuration QR code in SVG format
Render users list page or individual user detail page based on id parameter
CRITICAL: Tool descriptions are superficial or missing. Examples: 'Serve favicon file from assets' (21 chars), 'Return hello world text response' (32 chars), 'Render documentation page' (26 chars). None explain WHEN to use the tool, what preconditions exist, or what the response structure is. LLMs cannot select tools based on these descriptions.
CRITICAL: /db/write combines create, update, and delete operations into a single tool endpoint. This violates the single-responsibility principle. Agents cannot compose these independently, and error handling cannot distinguish which sub-operation failed.
CRITICAL: No error handling visible. Tools like /db/read and /db/write include .catch() handlers, but error responses are not documented. LLMs receive raw errors with no recovery guidance. For example, what should the LLM do if /db/read fails? Retry? Call a different tool?
HIGH: Parameter descriptions lack specificity. For /qrcode/napas, parameters like 'bank' (description: 'Bank code (default: vcb)') do not specify valid enum values, format (e.g., is vcb a SWIFT code? A BIN?), or length constraints. Agents must guess valid inputs.
HIGH: Output schemas are not documented for any tool. Tools return JSON (e.g., /db/read returns find, find_short, find_complex, first, list, etc.) but the response structure is never formally defined. LLMs cannot plan downstream calls or extract fields reliably.
HIGH: /screenshot accepts a 'url' parameter with default 'https://github.com' but provides no validation (URL format, allowed domains, timeout, max file size). Agents could trigger expensive operations or security issues without constraints.
HIGH: Tools are web endpoints masquerading as MCP tools. The framework (Kitwork) appears to be a web framework, not an MCP-native implementation. Tools are registered via router.get(), not an MCP tool registry. This suggests the server may not be a true MCP server but rather an HTTP service with a loose MCP interface.
MEDIUM: No permission checks or security gates. Database write operations (/db/write) are exposed without authentication, authorization, or audit logging. Tools can create, update, or delete data with no access control.
MEDIUM: GET /* is a catch-all route that accepts arbitrary paths. This creates ambiguity: which tool does the LLM call? How does it know what parameters to pass? Catch-all routes defeat tool discovery and clarity.