quran-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'GET-chapter', 'info', and 'list-chapters' that could cause confusion, as they all relate to chapter information. The verses retrieval tools are well-differentiated by their indexing methods (e.g., chapter number, juz number).
Naming Consistency2/5
Naming is inconsistent with mixed conventions: some use snake_case (e.g., 'random_verse'), some use kebab-case (e.g., 'chapter-reciters'), some use camelCase (e.g., 'verses-by_chapter_number'), and one uses uppercase prefix ('GET-chapter'). There is no uniform verb_noun pattern, making it harder to predict tool names.
Tool Count3/5
With 20 tools, the count is borderline high for a Quran-focused server, but it covers various aspects like chapters, verses, recitations, tafsirs, and translations. It feels slightly heavy but still manageable given the domain's complexity.
Completeness5/5
The tool set provides comprehensive coverage for accessing Quranic content, including chapters, verses by multiple indices, recitations, translations, tafsirs, and search functionality. There are no obvious gaps for typical agent workflows in this domain.
Average 2.8/5 across 20 of 20 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 status not available
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

Behavior1/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 but fails completely. 'Get Chapter' doesn't indicate whether this is a read-only operation, what format the response takes, whether authentication is required, or any rate limits or constraints. The description provides zero behavioral information beyond the basic action implied by the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this description suffers from severe under-specification rather than effective conciseness. The two words don't provide enough information to be useful, making this an example of being too brief rather than appropriately concise. Good conciseness balances brevity with sufficient information, which this lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of having 2 parameters, no annotations, no output schema, and multiple sibling tools that appear related, the description is completely inadequate. It doesn't explain what 'chapter' refers to in this context (likely Quran chapters based on sibling tools), what information is returned, or how this differs from other chapter-related operations. The description fails to provide the minimal context needed for effective tool 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?
The schema description coverage is 100%, so both parameters (id and language) are fully documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Chapter' is a tautology that essentially restates the tool name without providing meaningful context. It doesn't specify what resource is being retrieved (e.g., Quran chapter content, metadata, or structure) or distinguish this from sibling tools like 'list-chapters', 'verses-by_chapter_number', or 'tafsir' that might also retrieve chapter-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools that appear related to chapters (list-chapters, verses-by_chapter_number, tafsir, etc.), there's no indication of what makes this tool distinct or when it should be preferred over other chapter-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but provides none. 'List Chapters' doesn't indicate whether this is a read-only operation, whether it requires authentication, whether it's paginated, what format the output takes, or any rate limits. For a tool with no annotation coverage, this complete lack of behavioral information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective conciseness. The description doesn't front-load important information or provide any structure - it's simply the tool name repeated. Every sentence should earn its place, but here there's essentially no sentence to evaluate for value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of having many sibling tools, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, or how it differs from similar tools. For a listing operation in a domain with multiple related tools, this minimal description fails to provide the necessary context for an agent to 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?
The schema description coverage is 100%, with the single parameter 'language' well-documented in the schema itself. The description adds no parameter information beyond what the schema provides. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Chapters' is a tautology that essentially restates the tool name without providing meaningful context. It doesn't specify what resource is being listed (e.g., Quran chapters, book chapters) or what the scope of the listing includes. While the name implies chapters of something, the description fails to add any clarifying information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus the many sibling tools available. There's no mention of alternatives like 'GET-chapter' (which might retrieve a single chapter) or 'verses-by_chapter_number' (which might get verses within a chapter). The agent receives no help in determining when this list operation is appropriate versus other listing or retrieval operations.
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 doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. The description only states the purpose without any 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 'List of Chapter Reciters' is extremely concise with zero waste—a single phrase that front-loads the core purpose. It's appropriately sized for a simple listing tool, though this conciseness comes at the cost of detail.
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 complexity (simple listing with 1 parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'Chapter Reciters' refers to (e.g., Quran reciters), the return format, or any behavioral aspects, leaving 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?
The input schema has 1 parameter with 100% description coverage ('language: Name of reciters in specific language'), so the schema does the heavy lifting. The description adds no meaning beyond the schema, as it doesn't mention parameters at all. Baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List of Chapter Reciters' states a general purpose (listing reciters) but lacks specificity about what resource is being listed (e.g., Quran chapter reciters) and doesn't distinguish from siblings like 'recitation-styles' or 'languages'. It's vague about the exact domain, though it implies a listing operation.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention siblings like 'recitation-styles' or 'languages', nor does it specify prerequisites or context for usage. The description offers no explicit or implied 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 of behavioral disclosure. 'Get Chapter Info' implies a read-only operation, but it doesn't specify whether authentication is required, rate limits apply, what format the information is returned in, or any error conditions. The description adds minimal behavioral context beyond the basic action.
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 at just three words, with no wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in this minimal formulation.
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 insufficiently complete. For a tool with 2 parameters (one required) and no structured output documentation, 'Get Chapter Info' doesn't explain what information is returned, how results are formatted, or any behavioral constraints. The description leaves too many contextual gaps for effective tool selection.
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 both parameters ('chapter_id' and 'language') well-documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Chapter Info' clearly states the action (Get) and resource (Chapter Info), but it's vague about what specific information is retrieved. It doesn't distinguish this tool from similar siblings like 'GET-chapter' or 'chapter-reciters' that might also provide chapter-related information.
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. With many sibling tools related to chapters (e.g., 'GET-chapter', 'chapter-reciters', 'list-chapters'), there's no indication of what makes this tool unique or when it should be preferred over others.
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. 'Get all languages' implies a read-only operation, but it doesn't disclose behavioral traits such as whether it returns a list, supports filtering via the 'language' parameter, has rate limits, or requires authentication. This is a significant gap 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 extremely concise with just three words, front-loaded and zero waste. Every word earns its place by stating the core action and resource, making it efficient for quick understanding.
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 vague purpose, the description is incomplete. It doesn't explain what 'languages' are in this context, how the parameter works, or what the return values look like. For a tool with 1 parameter and unclear scope, it should provide more context to be fully helpful.
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 1 parameter with 100% description coverage ('language' described as 'Language'), so the schema does the heavy lifting. The description doesn't add any meaning beyond this, such as explaining how the parameter filters results or its expected format. Baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all languages' clearly states the verb ('Get') and resource ('languages'), but it's vague about what 'languages' refers to (e.g., programming languages, natural languages, Quran translations) and doesn't distinguish from siblings like 'translations' or 'tafsirs'. It's functional but lacks specificity.
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?
No guidance is provided on when to use this tool versus alternatives. Given sibling tools like 'translations' and 'tafsirs' that might relate to languages, the description doesn't clarify its unique context or exclusions, leaving the agent to infer usage.
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 a read operation ('Get list') but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the list is in. 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 with no wasted words. It's front-loaded and appropriately sized for a simple tool, 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 and no output schema, the description is incomplete. It doesn't explain what 'translations' refers to (e.g., Quran translations), the return format, or any behavioral context. For a tool in a context with many siblings, more detail is needed to ensure proper 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%, with one parameter 'language' documented in the schema. The description doesn't add any meaning beyond the schema—it doesn't explain what the 'language' parameter does (e.g., filter by language) or provide examples. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of available translations' states a clear verb ('Get') and resource ('translations'), but it's vague about what 'available translations' means—translations of what? It doesn't distinguish from siblings like 'translation-info' or 'languages', leaving ambiguity about scope.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'translation-info' and 'languages', the description lacks any context about differences, prerequisites, or exclusions, offering no help in tool selection.
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. 'Get' implies a read-only operation, but it doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what happens with invalid keys. The description is too minimal to provide meaningful behavioral context for a tool with 9 parameters.
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 at 3 words, front-loaded with the core purpose. There's zero wasted language, though this conciseness comes at the cost of completeness for other dimensions.
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 complexity (9 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what a 'verse' includes, what optional parameters like 'audio' or 'tafsirs' do, or what the return format looks like. For a data retrieval tool with many customization options, more context is needed.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'verse_key' is the primary identifier. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get verse by key' states the basic action (get) and resource (verse), but is vague about what constitutes a 'verse key' and doesn't differentiate from sibling tools like 'verses-by_chapter_number' or 'random_verse'. It lacks specificity about what data is retrieved beyond the verse itself.
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?
No guidance is provided on when to use this tool versus alternatives. With multiple sibling tools for retrieving verses (e.g., 'verses-by_chapter_number', 'random_verse'), the description offers no context about when this key-based lookup is appropriate or what distinguishes it from other verse retrieval methods.
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. 'Get a random verse' implies a read-only operation, but it fails to specify aspects like whether the randomness is weighted, if there are rate limits, authentication requirements, or what the output format includes. This leaves significant gaps in understanding the tool's 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 just three words, front-loading the core purpose without any wasted text. It efficiently communicates the essential action, making it easy to parse and understand 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 the complexity of 8 parameters and no annotations or output schema, the description is incomplete. It does not explain how parameters like 'tafsirs' or 'translations' influence the result, what the return values look like, or any behavioral traits. For a tool with rich optional parameters, more context is needed to guide 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?
The input schema has 100% description coverage, so the schema already documents all 8 parameters (e.g., 'audio', 'fields', 'language'). The description adds no additional meaning or context about these parameters, such as how they affect the random selection or output. With high schema coverage, the baseline score of 3 is appropriate.
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 'Get a random verse' clearly states the verb ('Get') and resource ('a random verse'), making the purpose immediately understandable. However, it does not differentiate from sibling tools like 'verses-by_chapter_number' or 'search', which might also retrieve verses but with different scopes or methods.
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 lacks context such as whether this is for quick access, educational purposes, or specific use cases compared to other verse-retrieval tools in the sibling list, leaving the agent to infer usage.
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 the tool searches for 'specific terms' but doesn't mention how results are returned (e.g., format, pagination details), whether it's case-sensitive, if it supports advanced operators, or any rate limits. This leaves significant gaps in understanding the tool's 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 that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core functionality, making it easy to understand at a glance.
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 complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the search returns (e.g., verses, chapters, metadata), how results are structured, or any behavioral nuances. For a tool that likely returns complex results, more context is needed.
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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how the 'q' parameter interacts with Quranic text or typical search patterns. Baseline 3 is appropriate when the schema handles parameter documentation.
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 ('Search') and resource ('the Quran'), making the purpose immediately understandable. However, it doesn't differentiate this search tool from other Quran-related tools on the server, such as 'verses-by_chapter_number' or 'tafsir', which might also involve searching or retrieving content.
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. With multiple sibling tools like 'verses-by_chapter_number' or 'tafsir' that might retrieve Quranic content, there's no indication of when a full-text search is preferable over structured verse retrieval.
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 it's a read operation ('Get'), which implies safety, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'tafsir' entails (e.g., religious commentary). This leaves significant gaps for a tool with 8 parameters.
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 a single tafsir'). There's no wasted wording, making it easy to parse quickly, though it could benefit from more context given the lack of annotations.
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 complexity (8 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what a 'tafsir' is, how parameters interact (e.g., if 'tafsir_id' is required, what do other parameters do?), or the return format, leaving the agent with insufficient context for 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%, with each parameter clearly documented in the schema (e.g., 'chapter_number' as 'Chapter number'). The description adds no additional meaning beyond the schema, but since the schema is comprehensive, the baseline score of 3 is appropriate as it doesn't detract value.
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 ('a single tafsir'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'tafsirs' (which likely lists multiple tafsirs) or 'tafsir-info' (which might provide metadata), leaving some ambiguity about when to choose this specific tool.
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. With siblings like 'tafsirs' and 'tafsir-info', there's no indication of how this tool differs in context or functionality, leaving the agent to infer usage from the name alone.
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 ('Get'), implying it's likely safe, but doesn't disclose any behavioral traits like authentication needs, rate limits, error handling, or what the information includes, which is insufficient for a tool with no structured safety hints.
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 with zero waste. It's front-loaded and appropriately sized for a simple tool, 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 and no output schema, the description is incomplete. It lacks details on what the information includes, how it's returned, or any behavioral context, which is inadequate for a tool that might return complex data about tafsirs.
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 the single parameter 'tafsir_id'. The description adds no additional meaning beyond implying it's for a specific tafsir, which aligns with the schema but doesn't provide extra context like format examples or constraints.
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 ('information of a specific tafsir'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'tafsir' or 'tafsirs', which likely have related functionality, 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. With siblings such as 'tafsir' and 'tafsirs' present, there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
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 only states the basic action ('Get list') without mentioning whether this is a read-only operation, if it requires authentication, what the return format looks like, or any rate limits. For a tool with zero annotation coverage, this is insufficient.
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 with zero wasted words. It's front-loaded with the core purpose, making it easy to parse and understand immediately.
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 a 'tafsir' is in this context, what the returned list contains, or any behavioral traits. For a tool with no structured support, more context is needed to be fully helpful.
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 schema description coverage is 100%, with the single parameter 'language' documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where the schema handles 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 action ('Get list') and resource ('available tafsirs'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'tafsir' or 'tafsir-info', which prevents a perfect score, but it's unambiguous about what the tool does.
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 like 'tafsir' or 'tafsir-info'. It lacks any context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage from the purpose alone.
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 'Get information' which implies a read-only operation, but doesn't specify what information is returned (e.g., metadata, status), potential errors, or any constraints like rate limits or authentication needs. 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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential purpose without redundancy.
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 doesn't explain what 'information' includes (e.g., fields returned), error conditions, or behavioral traits. For a tool that likely returns structured data about translations, this lack of detail makes it inadequate for full contextual understanding.
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 'translation_id' documented as 'Translation id'. The description adds no additional meaning beyond this, such as format examples or context about what a translation_id represents. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 of a specific translation', making the purpose understandable. It distinguishes from siblings like 'translations' (likely listing translations) by focusing on a specific translation, though it doesn't explicitly contrast with 'tafsir-info' or other info 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 doesn't mention prerequisites (e.g., needing a translation_id), exclusions, or comparisons to sibling tools like 'translations' or 'tafsir-info', leaving usage context implied rather than 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get verses', implying a read-only operation, but doesn't clarify whether this is a safe read (e.g., no side effects), what the return format includes (e.g., verses with metadata), or any constraints like rate limits, authentication needs, or pagination behavior. The description lacks essential context for a tool with 11 parameters and 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 a single, efficient sentence: 'Get verses by Chapter / Surah number'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
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 complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral traits, return values, or usage guidelines, leaving significant gaps. For a tool with rich parameterization and sibling alternatives, more context is needed to help the agent invoke it correctly and interpret results.
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 description adds no parameter-specific information beyond what the input schema provides. Since schema description coverage is 100%, the baseline score is 3. The description doesn't explain how parameters like 'audio', 'tafsirs', or 'fields' interact with the core functionality, nor does it provide examples or clarify semantics (e.g., what 'ayah fields' or 'word fields' entail).
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 verses by Chapter / Surah number'. It uses a specific verb ('Get') and identifies the resource ('verses'), and the scope ('by Chapter / Surah number') is clear. However, it doesn't explicitly differentiate from sibling tools like 'verses-by_juz_number' or 'verses-by_page_number', which have similar structures but different filtering criteria.
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 sibling tools like 'verses-by_juz_number' or 'verses-by_verse_key', nor does it specify prerequisites, exclusions, or contextual cues for selection. The agent must infer usage based on the name alone, which is insufficient for optimal tool selection.
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 'Get verses' but does not disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (since no output schema exists). The description is minimal and lacks essential context for safe and effective use.
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 with zero waste. It is front-loaded and directly states the tool's purpose without unnecessary words. Every part of the description earns its place, making it highly concise and well-structured for quick understanding.
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 complexity (11 parameters, 1 required) and lack of annotations and output schema, the description is incomplete. It does not explain return values, error conditions, or behavioral constraints, leaving significant gaps for the agent. For a tool with many optional parameters and no output schema, more context is needed to ensure proper usage.
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 all 11 parameters. The description does not add any meaning beyond the schema, as it only mentions 'Hizb number' without detailing other parameters like 'audio', 'fields', or pagination options. With high schema coverage, the baseline score of 3 is appropriate, as the description relies on the schema for parameter semantics.
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 'Get verses by Hizb number' clearly states the action (get) and resource (verses), with the specific filter (by Hizb number). It distinguishes from siblings like 'verses-by_chapter_number' or 'verses-by_juz_number' by specifying the filtering criterion, though it doesn't explicitly contrast them. The purpose is unambiguous but lacks explicit sibling 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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools (e.g., 'verses-by_juz_number' or 'verses-by_chapter_number') or specify contexts where Hizb-based retrieval is preferred. Usage is implied by the name but not explained, leaving the agent to infer based on parameter needs.
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 but only states the basic action without disclosing behavioral traits such as pagination behavior (implied by 'page' and 'per_page' parameters), rate limits, authentication needs, or what the output looks like. It mentions 'Get' which suggests a read operation, but lacks details on response format or error handling.
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 with zero waste—'Get verses by Juz number'—front-loading the core purpose without unnecessary elaboration. It appropriately sized for the tool's complexity.
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 complexity (11 parameters, no output schema, no annotations), the description is insufficient. It lacks details on output format, error cases, or how parameters interact (e.g., combining 'audio' with 'translations'), leaving significant gaps for an AI agent to invoke 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%, so parameters like 'juz_number', 'audio', and 'fields' are documented in the schema. The description adds no additional semantic context beyond the tool's purpose, adhering to the baseline score when schema coverage is high.
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 'Get verses by Juz number' clearly states the action (get) and resource (verses), with the specific qualifier 'by Juz number' indicating the retrieval method. It distinguishes from siblings like 'verses-by_chapter_number' by specifying the Juz-based filtering, though it doesn't explicitly contrast them.
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?
No guidance is provided on when to use this tool versus alternatives like 'verses-by_chapter_number' or 'verses-by_page_number'. The description implies usage for Juz-based retrieval but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on parameter names alone.
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 'Get' which implies a read operation, but doesn't cover aspects like authentication needs, rate limits, or what the output format might be (e.g., list of styles with metadata). This leaves significant gaps for a tool with no structured safety hints.
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 function without any wasted words. It's front-loaded and appropriately sized for a simple tool with no parameters.
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 doesn't explain what 'available recitation styles' means in practice (e.g., audio formats, reciter names, or metadata), leaving the agent uncertain about the return values and usage context. This is inadequate for a tool that might involve audio or cultural specifics.
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 parameter details, which is appropriate here, but it could slightly enhance value by hinting at implicit context (e.g., if styles vary by language). Baseline is 4 for zero 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 verb ('Get') and resource ('available recitation styles'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'chapter-reciters' or 'languages' that might also relate to recitation or audio features, so it's not fully 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. With siblings like 'chapter-reciters' and 'languages' that could overlap in audio or recitation contexts, there's no explicit or implied direction on usage scenarios or 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 'Get list of all juzs' which implies a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, pagination, or response format. This leaves significant gaps for an agent to understand how 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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a tool with no parameters, making it highly efficient and easy to parse.
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 minimally adequate but lacks context about what a 'juz' is or how the list is structured. Without annotations or output schema, more detail on the return format would help, though the low complexity keeps it from being severely incomplete.
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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly implies no parameters are required, earning a baseline high score for this simple case.
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 with a specific verb ('Get') and resource ('list of all juzs'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'verses-by_juz_number' or 'hizb_number' tools, which prevents a perfect 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. With sibling tools like 'verses-by_juz_number' that might retrieve verses for a specific juz, there's no indication of whether this tool is for metadata listing or when it's preferred over other juz-related 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, what format the verses are returned in, whether there are rate limits, authentication requirements, or pagination behavior (despite having 'page' and 'per_page' parameters). The description is minimal and 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 states the core purpose without unnecessary words. It's appropriately sized for a retrieval tool and front-loads the essential information. Every word earns its place in conveying the tool's primary function.
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 tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the relationship between parameters (e.g., how 'audio', 'tafsirs', and 'translations' interact), what the return format looks like, or important behavioral constraints. The agent must rely entirely on the input schema for operational details.
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 11 parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'page number' but the schema already describes it as 'Madani Mushaf page number (1-604)'. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 all verses') and resource ('of a specific Madani Mushaf page'), with the page number range (1-604) providing precise scope. It effectively distinguishes this from sibling tools like 'verses-by_chapter_number' or 'verses-by_juz_number' by specifying the page-based retrieval method.
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?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for page-based retrieval, it doesn't mention when page-based access is preferable over chapter-based, juz-based, or other verse retrieval methods available in the sibling tools. The agent must infer usage context from the tool name alone.
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 'Get verses', implying a read-only operation, but doesn't disclose behavioral traits such as whether it's safe, if it requires authentication, rate limits, pagination, or what the output format looks like. The description is minimal and lacks essential context for a tool with 9 parameters.
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 with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy to scan and understand 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 the tool's complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a Rub el Hizb is, how the output is structured, or provide any context on the optional parameters' effects. For a data retrieval tool with many options, more guidance is needed to be fully helpful.
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 9 parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or enhance understanding.
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 'verses', specifying they are retrieved 'by Rub el Hizb number'. It distinguishes from siblings like 'verses-by_chapter_number' or 'verses-by_juz_number' by indicating the specific numbering system used. However, it doesn't explicitly mention what a 'Rub el Hizb' is or that it's a Quranic division, which could help further differentiate.
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 you have a Rub el Hizb number (1-240) to fetch verses, as seen in the schema. It doesn't provide explicit guidance on when to use this versus alternatives like 'verses-by_juz_number' or 'verses-by_page_number', nor does it mention prerequisites or exclusions. Usage is contextually inferred but not clearly stated.
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:

[![quran-mcp-server MCP server](https://glama.ai/mcp/servers/djalal/quran-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/djalal/quran-mcp-server)

Score Badge

Copy to your README.md:

[![quran-mcp-server MCP server](https://glama.ai/mcp/servers/djalal/quran-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/djalal/quran-mcp-server)

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/djalal/quran-mcp-server'

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