Loading ToolBench
Bible MCP Server for Cloudflare Workers - provides Bible search and verse retrieval tools
The server defines one tool 'bible_content' with a complete JSON Schema input definition and description. The tool supports multiple actions (search, verse, passage, chapter) via an enum parameter. However, the description conflates four distinct operations into a single tool, violating the single-responsibility principle. Parameter descriptions are present but inconsistent in detail. The schema is well-formed with proper types and enums, but the tool lumps too much functionality together, forcing the LLM to reason about which action to use rather than calling a semantically clear tool. Output schema is not documented in the source code provided.
Read and search Bible verses. Actions: search - Find verses by text (requires query); verse - Single verse e.g. GEN.1.1 (requires verse_id); passage - Verse range e.g. GEN.1.1-GEN.1.5 (requires passage_id); chapter - Full chapter (requires book_id, chapter). Use concise (default) for summaries; use detailed for verse numbers and full context.
Tool name 'bible_content' is not a verb-noun pair and does not clearly signal what action will be performed. The name alone does not convey whether the tool searches, retrieves, or processes Bible content. LLMs will struggle to choose between this and other hypothetical Bible tools.
Single tool 'bible_content' combines four distinct operations (search, verse, passage, chapter) under one tool. This violates the single-responsibility principle. Tools should be decomposed as 'search_bible_verses', 'get_bible_verse', 'get_bible_passage', 'get_bible_chapter' to enable clear intent signaling and independent reuse.
Parameter 'query' is only required for 'search' action, but this constraint is documented only in prose within the tool description, not enforced in the JSON Schema. When action='verse', 'passage', or 'chapter', query is irrelevant, but the LLM has no formal signal that it is conditionally required. This increases the risk of malformed calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schema is not documented in the source code. The tool description does not specify what fields are returned for each action (search results structure, verse text format, passage content format, etc.). LLMs cannot plan downstream operations or extract fields without knowing the response schema.
Parameter descriptions lack actionable format and constraint details. For example, 'verse_id' states format is 'BOOK.CHAPTER.VERSE (e.g., GEN.1.1, JHN.3.16)' but does not specify valid book codes, chapter ranges, or verse ranges for validation. 'passage_id' is similarly vague. These should specify constraints such as allowed book abbreviations and numeric ranges.
Error handling strategy is not visible in the provided source. No error recovery guidance, categorization of error types, or suggestions for fallback actions are documented in tool descriptions or schemas. If an invalid verse_id is passed, the LLM will receive an error but has no guidance on how to correct it or what to try next.
'limit' parameter defaults to 10 but accepts up to 200. The description does not warn that large limits may cause context window exhaustion or slow responses. For production use, the tool should either cap the default lower, enforce a strict maximum, or document token implications.