Loading ToolBench
MCP server that provides access to Kagi search and summarizer tools via Model Context Protocol, deployed as a containerized gateway with optional Home Assistant compatibility.
Two tools with minimal descriptions and incomplete schemas. Input schemas present but lack critical details like minItems constraints, format specifications, and return type documentation. No error handling guidance visible. Parameters have basic type definitions but lack detailed constraints and usage examples. No tool annotations (readOnlyHint) despite READ_ONLY risk classification. Output schemas are not documented.
Performs a Kagi search with specified queries and returns results.
Summarizes the content of a specified URL using Kagi's summarization service.
Tool descriptions are truncated and generic (under 20 characters). 'Performs a Kagi search with specified queries and returns results.' lacks guidance on when to use this tool vs alternatives, prerequisites, or what constitutes 'results'. 'Summarizes the content of a specified URL using Kagi's summarization service.' similarly lacks context.
Input schema for kagi_search_fetch lacks critical constraints: no minItems, maxItems, or limit bounds on 'queries' array. Agents could pass empty arrays or extremely large query sets. 'limit' parameter has no minimum/maximum range specified (e.g., 1-100).
Input schema for kagi_summarizer: 'summary_type' parameter description says 'Type of summary to generate (e.g., 'summary')', the example value will be reused literally by LLMs instead of exploring valid options. Should use enum constraint instead. No format specification for 'url' (should enforce valid URL format).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
No output schema documentation visible. LLMs cannot determine what fields to expect in responses. Without knowing if results include rank, snippet, relevance score, or metadata, agents cannot reliably chain these tools or extract the right data.
Tool definitions appear in test file (scripts/mcp_live_tool_test.mjs) rather than explicit server-side registration. Tool schemas are inferred from callTool arguments rather than declared via server's listTools response. Cannot verify actual tool registration mechanism or if names/schemas match what the server advertises.
No error handling guidance. No documentation of what happens when queries fail, URLs are unreachable, Kagi API returns 401/429/500, or rate limits are hit. LLMs have no recovery path if a tool call fails.
No pagination support visible. If kagi_search_fetch returns large result sets, LLMs cannot request page 2 or set per-page limits beyond the single 'limit' parameter. No next_cursor or total_count in documented responses.
Parameter descriptions lack format/constraint details. 'url' parameter should specify 'valid HTTP(S) URL'. 'limit' should state '1-100 results per query'. 'queries' should specify minimum 1 item, maximum array length. LLMs rely on descriptions to understand constraints, JSON Schema fields alone are not visible to them.
Tools marked READ_ONLY but no tool annotations (readOnlyHint) visible in schema. Modern MCP clients expect structured hints to optimize caching and determine if operations are safe to retry.