Loading ToolBench
An MCP (Model Context Protocol) server that exposes the Alfanous Quranic search engine as tools and resources for AI assistants.
The server defines 11 tools with generally clear naming and comprehensive parameter schemas. All tools start with action verbs (search_, get_, list_, suggest_, correct_) and have non-empty descriptions. Parameter schemas are well-structured with types, descriptions, and appropriate defaults. However, there are gaps: (1) Output schemas are not documented, we can infer results from descriptions but cannot verify actual response structure; (2) Error handling is not evident in the provided code, no recovery guidance or error classification visible; (3) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only operations; (4) Some parameter descriptions lack actionable constraints or examples. The Alfanous domain expertise is strong, the tool set covers search, linguistics, metadata, and filtering comprehensively, but the LLM-optimized presentation could be tighter.
Fix spelling mistakes before searching. Returns corrected query suggestions.
Retrieve metadata such as chapter names, translations, recitations, and AI query rules. Provides reference information about available Quranic resources.
Return the full schema and query syntax guide for word-level morphological data. Provides comprehensive documentation on word linguistic fields and query capabilities.
Enumerate all unique indexed values for a field. Returns a list of all possible values for a searchable field.
Search word occurrences by morphological properties: root, part of speech, gender, number, person, voice, aspect, derivation, form, and more. Returns individual words with full linguistic metadata.
Search for verses in the Holy Qur'an. The query supports Arabic text, Buckwalter transliteration, boolean operators (AND / OR / NOT), phrase search ("…"), wildcards (* and ?), field-specific searches (e.g. sura_id:2 aya_id:255), fuzzy matching, synonyms, antonyms, and root-level derivations. Returns a paginated list of matching verses with metadata.
Output schemas are not documented. While input parameters are well-defined with JSON Schema, the structure of responses (e.g., what fields search_quran returns, field types, pagination format) is not formally specified. LLMs cannot reliably parse or chain results without response documentation.
No tool annotations present. All 11 tools are read-only/safe operations (no state modification, no side effects), but readOnlyHint is not set. This prevents clients from optimizing caching, retry policies, or sandboxing decisions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Retrieve verses from a specific location such as a juz, hizb, page, sura, or verse number. Returns verses at the specified position(s) in the Qur'an.
Filter verses by numeric attributes such as word count or verse count in a sura. Returns verses matching specified statistical criteria.
Filter verses by thematic classification (chapter, topic, subtopic). Returns verses grouped and filtered by Islamic thematic categories.
Search within Quranic translation texts (e.g. English, French, Urdu). Use this tool when the query is in a non-Arabic language or when the user wants to find verses by their translated meaning. Optionally specify a translation identifier (see get_quran_info with category='translations' for available options). Returns a paginated list of matching translation snippets with verse metadata.
Get auto-completion suggestions for a partial query. Returns query completions starting with the given prefix.
Error handling and recovery guidance not visible in source code. No evidence of structured error responses, categorization (retryable vs. user-fixable), or suggestions for fallback actions. Descriptions like 'fuzzy_maxdist: Maximum Levenshtein edit distance' lack bounds validation hints or what happens on invalid input.
Parameter descriptions lack actionable constraints in several tools. For example, 'view' parameter accepts 'minimal', 'normal', 'full', etc., but these are listed as prose rather than enum constraints. Same for 'sortedby' (relevance/score/mushaf/tanzil/ayalength) and 'highlight' (bold/css/html/bbcode). Enums should be machine-readable.
get_word_children_schema tool has a generic description ('Return the full schema and query syntax guide…') that does not clearly explain WHEN an LLM should call it vs. directly using search_by_word_linguistics. This risks duplicate/wasted calls.