Quran MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is significant overlap between 'search_hadith' and 'search_hadith_by_topic' as well as 'search_quran' and 'search_quran_by_topic', which could cause confusion. The descriptions clarify that the 'by_topic' versions use predefined mappings, but the core functionality is similar, potentially leading to misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., get_cache_stats, list_surahs, search_hadith), with no deviations in style. This predictability makes it easy for agents to understand and use the tools without confusion.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for covering Quran and Hadith resources comprehensively. It includes a good mix of retrieval, listing, and search functions, though some redundancy (e.g., multiple search tools) might be trimmed without losing essential functionality.
Completeness5/5
The tool set provides complete coverage for accessing and exploring Quranic and Hadith content, including verses, surahs, translations, recitations, tafsir, and search capabilities. There are no obvious gaps; agents can perform all core operations needed for this domain without dead ends.
Average 3.4/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves a Hadith but does not disclose behavioral traits such as error handling (e.g., if hadith_number is invalid), performance (e.g., response time), or output format (e.g., text, metadata). The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one providing background on Hadiths. It is front-loaded with the core function, and the second sentence adds useful context without redundancy. However, it could be slightly more efficient by integrating the background more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It explains what the tool does but lacks details on behavior, output (e.g., what data is returned), error cases, or prerequisites. For a tool with 2 parameters and no structured output info, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (collection with enum options, hadith_number with minimum). The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage notes. Baseline 3 is appropriate as the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a specific Hadith from a collection' with a brief explanation of what Hadiths are. It uses a specific verb ('Get') and resource ('Hadith'), but does not explicitly differentiate from siblings like 'get_random_hadith' or 'search_hadith' beyond implying specificity by 'specific'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'specific Hadith' but does not clarify scenarios (e.g., when you know the exact collection and number) or contrast with siblings like 'search_hadith' for unknown numbers or 'get_random_hadith' for random access. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a verse with Arabic text and English translation, but does not mention potential rate limits, authentication needs, error handling, or output format details. This is a significant gap for a tool with no structured safety or behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's function and return. There is no wasted verbiage, and it efficiently communicates the core purpose, though it could be slightly more structured by explicitly separating purpose from behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, error cases, or behavioral constraints, which are crucial for an AI agent to invoke the tool correctly. The high schema coverage helps, but the description does not compensate for missing behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all parameters (surah, ayah, translation) with constraints and options. The description adds minimal value beyond the schema by implying the tool uses these parameters to fetch a verse, but does not provide additional semantic context or usage examples. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as retrieving a Quran verse with Arabic text and English translation, specifying the verb 'Get' and resource 'Quran verse'. It distinguishes from siblings like get_random_verse by indicating it returns a specified verse, but does not explicitly contrast with get_full_surah or get_surah_info, which are related but not direct alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_random_verse, get_full_surah, or search_quran. It mentions returning a specified verse, which implies usage for exact verse retrieval, but lacks explicit when-to-use or when-not-to-use statements, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a random verse, implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, or what 'random' entails (e.g., uniform distribution, caching). This leaves gaps for an agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose in the first sentence. The second sentence ('Great for daily inspiration!') adds motivational context but doesn't waste space on redundant details, making it efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output format, which could help an agent use it more effectively in a broader set of scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting both parameters thoroughly with defaults. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 without compensating or adding extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a random verse') and resource ('from the Quran'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_quran_verse' or 'search_quran', which might also retrieve Quran verses, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Great for daily inspiration!' which is motivational but not operational—it doesn't specify contexts, prerequisites, or exclusions compared to siblings like 'get_quran_verse' or 'search_quran'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this requires admin permissions, what specific statistics are returned, if it's a real-time snapshot or aggregated data, potential performance impact, or error conditions. The description is functional but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary elaboration. It's front-loaded with the main action and resource, and the 'for monitoring server performance' clause adds useful context without redundancy. Every word earns its place in this compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a monitoring tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what statistics are returned, their format, units, or interpretation. For a tool that presumably returns structured performance data, users need to understand what metrics to expect. The description leaves too much unspecified about the tool's output and operational characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It correctly focuses on the tool's purpose rather than attempting to document non-existent inputs. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('cache statistics') with a specific purpose ('for monitoring server performance'). It distinguishes from siblings by focusing on system metrics rather than Quran/Hadith content retrieval. However, it doesn't explicitly contrast with potential alternative monitoring tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'monitoring server performance' as a general context but doesn't specify prerequisites, frequency, or comparison with other monitoring approaches. No explicit when/when-not statements or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('List') but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what the output format is. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple list operation, the description is incomplete. It doesn't explain what 'available' means, how results are returned, or any limitations, which could confuse an agent trying to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero parameters, as the schema fully covers the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available Quran translations'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_reciters' or 'list_tafsir_sources', which list other resources, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or compare to siblings like 'list_surahs' or 'list_hadith_collections', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It mentions 'predefined topic mappings for better results' which adds some context about search methodology, but doesn't describe what the tool returns (Hadith texts? references? metadata?), error conditions, rate limits, or authentication needs. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey core functionality and usage suggestion. The topic list could be trimmed since it duplicates schema content, but overall structure is front-loaded with purpose and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what results look like (format, structure), success/error behavior, or how topic mappings work operationally. The description adds value through topic examples and AI suggestion context but doesn't compensate for missing behavioral and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description lists topic examples that match the schema's 'topic' parameter description, adding no new semantic information beyond what's in the structured fields. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search Hadith collections by common Islamic topics' with specific verb+resource. It distinguishes from sibling 'search_hadith' by emphasizing topic-based search with predefined mappings, though it doesn't explicitly contrast with 'search_quran_by_topic' which shares similar topic-based approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('common Islamic topics') and suggests AI can recommend topics based on user questions, but lacks explicit when-to-use guidance versus alternatives like 'search_hadith' (general search) or 'search_quran_by_topic'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the ability to include translations, which adds some behavioral context, but fails to disclose critical traits like response format (e.g., structured data, pagination), error handling, or performance considerations (e.g., size of output for long surahs). For a read operation with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all verses of a complete Surah') and adds a useful detail about translations. There is no wasted text, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It lacks details on return values (e.g., format, structure), error cases, or behavioral constraints, which are essential for an AI agent to use it correctly. The high schema coverage helps, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (surah number range, translation options). The description adds minimal value beyond the schema by noting translations can be included, but does not explain parameter interactions (e.g., how 'translation' relates to 'include_translation') or provide usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all verses of a complete Surah (chapter)', specifying it retrieves complete chapters rather than individual verses. It distinguishes from siblings like 'get_quran_verse' (single verse) and 'get_surah_info' (metadata), though not explicitly named. However, it could be more specific about what 'all verses' entails (e.g., Arabic text, numbering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a full chapter rather than a single verse (contrasting with 'get_quran_verse'), but does not explicitly state when to use this tool versus alternatives like 'get_surah_info' or 'search_quran'. No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'random' retrieval and 'daily inspiration', but fails to disclose critical behavioral traits such as whether the tool requires authentication, has rate limits, returns structured data (e.g., text, source, narrator), or handles errors. This leaves significant gaps for an agent to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core functionality ('Get a random Hadith from a collection') and followed by a brief use case ('Great for daily inspiration!'). Every word adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., Hadith text, metadata), error conditions, or operational constraints like rate limits. For a tool with no structured behavioral data, this leaves the agent under-informed about how to handle the response or potential issues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'collection' well-documented (optional, enum values, default behavior). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the significance of collection choices or how randomness is weighted. Thus, it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a random Hadith from a collection'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_hadith' or 'search_hadith_by_topic', which likely serve different purposes (e.g., specific vs. random retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 'daily inspiration', suggesting a context of random retrieval for motivational purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_hadith' (which might fetch a specific Hadith) or 'search_hadith_by_topic' (which might filter by topic), leaving the agent to infer based on the 'random' keyword.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all available Hadith collections', which implies a read-only operation, but doesn't specify if it's paginated, returns structured data, or has any limitations. For a tool with zero annotation coverage, this is insufficient to inform the agent about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'List all available Hadith collections.' It is front-loaded, efficient, and wastes no words, making it highly concise and well-structured for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on output format or behavioral traits. Without annotations or an output schema, the agent might be uncertain about the return value, making it incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is acceptable since there are no parameters to explain. A baseline of 4 is appropriate as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available Hadith collections', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_surahs' or 'list_tafsir_sources', which follow a similar pattern but for different resources, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention if this is for browsing collections before using 'get_hadith' or 'search_hadith', or how it relates to other listing tools. This lack of context leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'predefined topic mappings' and that the AI can suggest topics, but doesn't disclose key behavioral traits such as how results are returned (e.g., format, pagination), whether it's a read-only operation, potential rate limits, or error handling. This leaves gaps for an AI agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the purpose, the second lists topics and mappings, and the third adds AI context. There's no wasted text, but the third sentence could be more directly about tool usage rather than AI capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool with 3 parameters. It covers the purpose and topics but lacks details on behavioral aspects (e.g., result format, limitations) and doesn't compensate for the missing output schema. This makes it adequate but with clear gaps for an AI agent to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds minimal value by listing example topics, which overlaps with the schema's description for the 'topic' parameter. It doesn't provide additional semantics beyond what's in the schema, such as usage tips or constraints not covered there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the Quran by common Islamic topics' with 'predefined topic mappings to find relevant verses.' It specifies the verb (search), resource (Quran), and scope (by topic). However, it doesn't explicitly distinguish it from sibling tools like 'search_quran' or 'search_hadith_by_topic,' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing common topics and noting that 'The AI understands these topics and can suggest them to users,' which suggests when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like 'search_quran' or 'search_hadith_by_topic,' and doesn't mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a read-only operation but doesn't disclose behavioral traits like error handling (e.g., for invalid surah numbers), response format, or performance characteristics. The description is minimal and lacks context about what happens during execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key details. It's front-loaded with the main action and includes specific examples of information retrieved, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on output structure or error cases, which would be helpful for an agent to use it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'surah' fully documented in the schema (type, range, description). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'information about a Surah (chapter)', specifying what information is included: name, number of verses, and revelation type. It distinguishes from siblings like 'get_full_surah' (which likely provides more detailed content) by focusing on metadata, but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when basic surah metadata is needed, but doesn't explicitly state when to use this tool versus alternatives like 'list_surahs' (for listing all surahs) or 'get_full_surah' (for detailed content). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns an MP3 URL, which is useful, but doesn't mention other behavioral aspects like whether it requires authentication, has rate limits, caches results, or what happens with invalid inputs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and output. Every word earns its place—no fluff or redundancy. It's front-loaded with the core function and efficiently adds the output detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and output type but lacks details on error handling, authentication, or usage context. Without annotations or output schema, more behavioral and contextual information would improve completeness for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (surah, ayah, reciter) with descriptions, constraints, and defaults. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get audio recitation URL') and resource ('for a specific Quran verse'), distinguishing it from siblings like get_quran_verse (which likely returns text) or get_full_surah (which might return full surah content). It explicitly mentions the output format ('MP3 URL for listening'), which further clarifies its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when audio recitation is needed, but doesn't explicitly state when to use this tool versus alternatives like get_quran_verse (which might provide text) or list_reciters (which lists reciters). It mentions list_reciters for reciter options, providing some contextual guidance, but lacks explicit when/when-not instructions or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List all available' suggests a read-only operation, the description doesn't mention important behavioral aspects like whether the list is paginated, sorted, or filtered; whether it requires authentication; what format the output takes; or if there are rate limits. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's front-loaded with the core action and resource, and the parenthetical '(commentary)' provides helpful clarification. Every element serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does but lacks behavioral context about how it works (format, pagination, authentication needs). For a list operation with zero structured metadata, more behavioral disclosure would be beneficial to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (since there are no parameters to document). The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. No additional parameter semantics are needed beyond what the empty schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all available'), resource ('Tafsir (commentary) sources'), and scope ('with their languages and authors'). It distinguishes this tool from siblings like 'get_tafsir' (which retrieves specific commentary content) and 'list_translations' (which lists translations rather than commentary sources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need to know what commentary sources exist), but doesn't explicitly state when to use this versus alternatives. For example, it doesn't clarify if this should be used before 'get_tafsir' to identify available sources, or if there are prerequisites like authentication. The guidance is functional but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'powerful tool' and 'search through the entire Quran' but doesn't disclose important behavioral traits like rate limits, authentication requirements, search algorithm characteristics, or what happens with ambiguous queries. It does mention 'natural language queries' which adds some context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each add value: purpose statement, use case examples, and natural language capability. It's front-loaded with the core functionality. Could be slightly more concise by combining some concepts, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has gaps. It explains the 'why' and 'when' well but doesn't address behavioral aspects like performance characteristics, result format, or error conditions that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'keywords or phrases' which aligns with the query parameter, and 'specific topics' which relates to query usage, but adds minimal semantic value beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the Quran by keywords or phrases' with specific examples like 'patience', 'prayer', 'mercy'. It distinguishes from siblings like get_quran_verse (which requires exact references) and search_quran_by_topic (which likely uses topic categorization rather than keyword search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'without knowing the exact surah and ayah numbers' and 'Perfect for finding verses about specific topics'. It implies when to use this tool (for keyword/concept searches) but doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool provides 'scholarly interpretation and context,' which adds behavioral context beyond a basic fetch. However, it lacks details on permissions, rate limits, error handling, or output format (e.g., text length, structure), leaving gaps for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose, and the second elaborates on the content provided. It is front-loaded with the core function and efficiently adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is somewhat complete for a read-only tool but lacks details on behavioral aspects like output structure or error cases. It covers the purpose and hints at usage via the schema, but more context on what the return looks like would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly (e.g., surah range, ayah minimum, tafsir default and alternative tool). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get Tafsir') and resource ('for a specific Quran verse'), distinguishing it from siblings like get_quran_verse (which likely returns the verse text) or list_tafsir_sources (which lists available sources). It explicitly mentions 'scholarly interpretation and context' to clarify what Tafsir entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when seeking commentary on a Quran verse, and the input schema's description for the 'tafsir' parameter references list_tafsir_sources as an alternative for exploring options. However, it does not explicitly state when not to use this tool (e.g., vs. get_quran_verse for just the text) or other exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists reciters but does not disclose behavioral traits like whether it requires authentication, rate limits, pagination, or error handling. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose without any wasted words. It is appropriately sized for a simple list tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is minimally complete but lacks behavioral context. Without annotations or output schema, it should ideally mention what the list returns (e.g., format, metadata) to be fully helpful, but it suffices for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add param info, but with no params, a baseline of 4 is appropriate as it adequately addresses the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('all available Quran reciters for audio recitations'), distinguishing it from siblings like list_surahs or list_translations. It precisely communicates what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing reciters for audio recitations, providing clear context. However, it does not explicitly state when not to use it or name alternatives (e.g., get_recitation_url for a specific reciter), missing full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details: it doesn't mention if this is a read-only operation, how data is returned (e.g., format, pagination), performance characteristics, or any limitations. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('List all 114 Surahs') and adds necessary detail ('of the Quran with their names and basic information'). Every word earns its place with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but not fully complete. It specifies the resource and output content (names and basic information), but without annotations or output schema, it lacks details on return format, ordering, or any behavioral constraints. For a read operation with no structured output documentation, it should ideally describe the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, and it correctly indicates no inputs are required. Baseline for 0 parameters is 4, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all 114 Surahs') and resource ('Quran'), and distinguishes it from siblings like get_surah_info (which gets detailed info for one surah) or search_quran (which searches verses). It provides exact count (114) and specifies the content (names and basic information).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need a complete list of Quran chapters), but doesn't explicitly state when not to use it or name alternatives. For example, it doesn't contrast with get_surah_info for detailed info on a specific surah or search_quran for verse-level queries, though the purpose distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching across collections and example query types, but lacks details on permissions, rate limits, error handling, or result format. It adds some context but doesn't fully disclose behavioral traits for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose, followed by usage context and examples. Every sentence adds value: first defines the tool, second specifies scope and use case, third provides concrete examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 100% schema coverage, and no output schema, the description is reasonably complete. It covers purpose, usage, and scope, though could benefit from mentioning result structure or limitations. Good given the structured data available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description implies keyword/phrase searching and collection options but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Hadith collections by keywords/phrases, distinguishing it from siblings like get_hadith (likely by ID), search_hadith_by_topic (topic-based), and search_quran (different resource). It specifies the verb 'search' and resource 'Hadith collections' with scope across major collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Find hadiths about specific topics without knowing exact hadith numbers' and 'Perfect for queries like...'. Distinguishes from alternatives by mentioning search across all or specific collections, contrasting with sibling tools like search_hadith_by_topic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![quranMCP MCP server](https://glama.ai/mcp/servers/Prince77-7/quranMCP/badges/card.svg)](https://glama.ai/mcp/servers/Prince77-7/quranMCP)

Score Badge

Copy to your README.md:

[![quranMCP MCP server](https://glama.ai/mcp/servers/Prince77-7/quranMCP/badges/score.svg)](https://glama.ai/mcp/servers/Prince77-7/quranMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Prince77-7/quranMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server