Loading ToolBench
MCP server that searches AWS Bedrock Knowledge Base for documentation of CloudFlare infrastructure and Model Context Protocol specification
Single tool with minimal schema and generic description. The tool 'search_knowledge_base' has a basic input schema (string query parameter) but lacks parameter description, output schema documentation, and comprehensive error handling guidance. Description is present but generic and does not explain when to use this tool vs alternatives, what structure it returns, or recovery paths on failure. No validation rules, pagination support, or field-level details visible. Tool definition is explicitly registered in cdk/lambda/mcpServer/index.ts using server.tool(), so it scores above the 'inferred' cap of 50.
Search for documentation of CloudFlare infrastructure and Model Context Protocol specification.
Parameter 'query' has no description. The rubric requires every parameter to have a description explaining what it controls. 'query' alone does not tell the LLM whether it expects a keyword, a phrase, a document ID, or a natural language question.
Output schema not documented. The tool returns CallToolResult['content'] mapped from Bedrock results, but there is no explicit schema showing what fields are in each result object, what type of 'text' content is returned, or whether pagination/limits apply. LLMs cannot plan downstream calls without knowing the response structure.
No result limits or pagination support visible. The tool returns all results from Bedrock without declared limits. If Bedrock returns 500+ items, the response will blow the context window. The tool description does not state a limit or mention pagination.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Description is generic and does not explain WHEN to use this tool or WHAT it returns. Current description: 'Search for documentation of CloudFlare infrastructure and Model Context Protocol specification.' This reads like a mission statement, not a usage guide. A production description should say: 'Retrieve relevant documentation snippets from the knowledge base. Returns text excerpts. Returns up to 20 results; use page parameter for more.'
No error handling guidance. The async handler catches no errors and provides no recovery hints. If retrieveFromBedrock() fails or returns empty results, the LLM receives no instruction on what to do next (retry? try a different query? ask the user?). Tool should return structured error responses with actionable guidance.
No tool annotation hints (readOnlyHint, destructiveHint, idempotentHint). While this tool is clearly read-only, the code does not explicitly annotate it. Production tools should declare their safety characteristics so clients can make informed decisions about retries and confirmations.