Loading ToolBench
MCP server for Dorar Hadith API - Provides LLM tools to search and retrieve Islamic hadith data
The server defines 15 tools with consistent verb-noun naming patterns (search_*, get_*, list_*). Most tools have descriptions (100%), and input schemas are present and mostly well-formed with type definitions. However, descriptions are often terse (many under 100 chars), parameter descriptions lack constraint details (e.g., no mention of valid values, ranges, or formats), and output schemas are entirely absent from the code. The server exhibits good structural organization but falls short on LLM-optimization and completeness. Tool names are clear but some descriptions underdescribe the semantic difference between similar tools (e.g., get_hadith_usul vs get_similar_hadiths). No security annotations, no error recovery guidance, and no pagination documentation visible in parameter schemas.
Get the alternate authentic version of a hadith
Retrieve information about a hadith book by its ID
Get list of all hadith books available in the database
Get list of all hadith grading degrees available
Retrieve a specific hadith by its ID
Get the sources and origins of a hadith
Retrieve information about a muhadith (hadith scholar) by ID
Get list of all muhadith (hadith scholars) available
Missing output schemas: Code shows input schemas but no documented return types. LLMs cannot plan downstream chaining or extract required fields without knowing what each tool returns (e.g., does get_hadith_by_id return a single object or array? What fields are present?). Every tool should declare its output structure.
Parameter descriptions lack constraint details. For example, search_hadith has parameters 'st' (enum: [w, a, p]), 'degree' (array), 'muhadith' (array), but descriptions do not explain: (a) what the enum values mean (w=all words, a=any word, p=phrase?); (b) what format the array elements take (IDs? names? strings?); (c) whether arrays are required or optional. This forces LLMs to guess at valid input formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Get list of all rawi (hadith transmitters) available
Retrieve sharh (hadith commentary) by its ID
Get sharh explanation for specific hadith text
Get hadiths similar to a given hadith ID
Analyze grading consensus for hadiths matching a search query
Search for hadiths using the Dorar API
Search for sharh (hadith commentary) by text
Semantic distinction between similar tools is not explicit. get_hadith_usul (sources/origins), get_similar_hadiths (similar versions), and get_alternate_hadith_sahih (alternate authentic version) all retrieve related hadiths, but the descriptions do not clarify when to call which. An LLM must infer from the tool name alone, risking wrong selection.
List/discovery tools (get_books_data, get_degrees_data, get_mohdith_data, get_rawi_data) have minimal descriptions (50 chars). These are typically called early in flows to understand what values to pass to filter/search tools. Descriptions should explain: (a) when to call them; (b) what structure they return; (c) whether results are paginated or complete.
No pagination guidance in search tools. search_hadith and search_sharh accept 'page' parameters but do not document: (a) default page size; (b) maximum results per page; (c) total result count in response; (d) whether pages are 0-indexed or 1-indexed. Without this, LLMs cannot reliably iterate through large result sets.
No error handling or recovery guidance. The code snippet does not show try-catch blocks, validation, or error messages. If a tool call fails (e.g., invalid hadith ID, malformed search query), what does the LLM receive? Without actionable error messages ('Try search_hadith() first'), the agent stalls.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only, but this is not declared in the schema. Tool annotations help clients and agents reason about safety and retryability. Code snippet shows all tools are safe, but this is not explicitly marked.