Loading ToolBench
A Model Context Protocol server for Bible study and theological research
TheologAI presents a thematically coherent tool suite for biblical and theological research with READ_ONLY semantics dominating (10 of 11 tools). However, the implementation shows critical gaps in schema rigor, parameter descriptions, and output documentation. Tool names follow action-verb conventions (bible_lookup, commentary_lookup, etc.), which is positive. Descriptions are present but often lack specificity about what data is returned, when to use each tool versus similar ones, and how to chain them. Parameter schemas are visible and typed, but descriptions are minimal or missing depth. No tool annotations (readOnlyHint/destructiveHint) are declared despite clear intent. Error handling and recovery guidance are not evident from the source provided. The donation-related tools (donation_config as WRITE, verify_donation as READ_ONLY) introduce a security concern with token-based verification that lacks clear validation semantics.
Find cross-references and related passages for a given Bible verse
Look up Bible passages and verses
Analyze Greek and Hebrew morphology and grammar for Bible verses
Search classic theological and historical texts
Look up theological commentary on Bible passages from classic sources
Configure donation and support settings
Look up Hebrew and Greek words with Strong's concordance numbers and lexicon definitions
Output schemas not documented. Tools return data but the structure (fields, types, pagination) is not visible in provided source. LLMs cannot plan downstream operations without knowing what fields to expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. Despite 10 tools being READ_ONLY and 1 being WRITE, the toolExecutionObserver does not expose these hints to the MCP protocol layer, denying the client visibility into which tools are safe to retry or modify state.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Comprehensive study of original language words with morphology, lexicon, and usage
Find parallel passages across different Gospel accounts and related texts
Search primary source historical documents and church fathers
Verify donation status and coverage
donation_config and verify_donation lack clear validation semantics. donation_config accepts a 'feature' string with no enum constraint or description of valid feature names. verify_donation accepts a 'donation_token' with no format, length, or validation rules documented. Token verification tools risk accepting arbitrary strings without feedback on what constitutes a valid token.
Weak differentiation between similar tools. bible_lookup, parallel_passages, and bible_cross_references operate on the same domain but lack clear guidance on when to use each. Descriptions do not explain: What does parallel_passages return that cross_references does not? When should an agent call one vs. another?
No error recovery guidance. Tool descriptions do not indicate what happens on failure (e.g., 'If reference not found, try a shorter passage like John 3 instead of John 3:16-18'). LLMs receive no actionable recovery paths.
Parameter descriptions lack specificity. Examples: primary_source_search's 'searchDepth' enum (basic|expanded) is documented but the expandedLimit integer has no min/max bounds. original_language_lookup's detail_level enum (basic|detailed) is present but the strongs_number parameter lacks format guidance (e.g., 'G25 for Greek, H430 for Hebrew').
No pagination or result-limit guidance. Tools like primary_source_search and classic_text_lookup do not declare a max result count or whether pagination is available. Large result sets risk context window exhaustion.