AskSakina Islamic Knowledge

Server Details

Curated Islamic MCP: Quran (Arabic + Pickthall), 440 du'as, 99 Names, crisis-aware.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.7% over 18 days
Last Tested: 2026-10-17 00:51
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: yserrag/asksakina-mcp
GitHub Stars: 0
Server Listing: AskSakina Islamic Knowledge MCP Server

TDQS

A3.9/5.0

Scored 2026-09-29 16:00 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: find_verses for thematic search, get_quran_verse for reference lookup by surah/ayah, get_dua for life contexts, and get_name_of_allah for the 99 Names. The two Quran tools differ by retrieval method (topic vs. exact reference), so an agent can tell them apart without confusion.

Naming Consistency5/5

All four tools follow a consistent verb_noun pattern (find_verses, get_dua, get_name_of_allah, get_quran_verse). There is no mixing of conventions or vague verbs.

Tool Count5/5

Four tools are well-scoped for a focused Islamic knowledge server, covering three distinct resource types without redundancy. Each tool earns its place and the count is neither thin nor bloated.

Completeness3/5

The surface covers Quran verses (by topic and reference), du'as, and the Names of Allah, but lacks any hadith, tafsir, or broader fiqh tools that users of an 'Islamic Knowledge' server might expect. This is a notable gap for the stated scope.

Available Tools

4 tools

find_versesfind_versesAInspect

Searches AskSakina's thematic index for Quran verses by topic keyword. Returns reference, Tanzil Arabic and Pickthall English. Quote the Arabic exactly.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of verses to return; default 5, max 10.
`query`	Yes	Topic or keyword, e.g. 'patience', 'grief', 'gratitude', 'hope'.
`locale`	No	Selects the in-country crisis resources if one is needed; defaults to "en". Translations are Pickthall English.
`audience`	No	Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose the return payload (reference, Tanzil Arabic, Pickthall English) and adds a genuine output-handling rule ('Quote the Arabic exactly'), but says nothing about empty results, result ranking, or why locale affects crisis resources rather than translation.

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 short sentences, front-loaded with what the tool does, then the return shape, then a single actionable constraint. No filler or repetition.

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?

This is a simple read-only keyword search with 100% schema coverage, and the description substitutes for the missing output schema by naming the returned fields. It is close to complete, though the unusual locale/crisis-resource coupling is left unexplained.

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 all four parameters (query, limit, locale, audience) are already documented in the schema with examples, bounds, and enum meanings. The description adds no additional parameter semantics, so the baseline 3 applies.

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?

States a specific verb and resource ('Searches AskSakina's thematic index for Quran verses') and the retrieval mode ('by topic keyword'), which implicitly separates it from a reference-based verse lookup. It does not name or contrast with the close sibling get_quran_verse, so routing still requires inference.

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?

Usage is implied by 'by topic keyword' – an agent can infer this is for topical lookup rather than lookup by surah/ayah reference – but there is no explicit when-to-use, when-not-to-use, or named alternative among get_quran_verse, get_dua, and get_name_of_allah.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_duaget_duaBInspect

Returns du'as from a curated du'a corpus for a life context (e.g. anxiety, travel, gratitude), with source and grading where recorded. Show any crisis_resource block verbatim.

ParametersJSON Schema

Name	Required	Description
`id`	No	A du'a id taken from a related reference in an earlier response. Send this or context, not both.
`locale`	No	Translation locale; defaults to "en". v1 returns English content for all locales.
`context`	No	Life context to match against. Examples: 'anxiety', 'morning', 'travel', 'forgiveness', 'gratitude'. Send this or id, not both.
`audience`	No	Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does disclose output traits (curated corpus, source and grading 'where recorded') and a genuine safety instruction to show any crisis_resource block verbatim, which is valuable. However, it says nothing about failure behavior for a missing id/context, locale fallback, or result limits.

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 tight sentences with no filler, and the core purpose is front-loaded. The verbatim-display instruction is appended rather than integrated, but it earns its place as an operational rule.

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 4-param tool with no annotations and no output schema, the description covers purpose, output nature, and a safety directive reasonably well. Still missing are the mutually exclusive id/context rule, locale fallback behavior, and empty-result handling, which leaves the agent guessing at edge cases.

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 4 well-documented parameters (id, locale, context, audience), so the baseline is 3. The description's example contexts ('anxiety', 'travel', 'gratitude') merely repeat the schema's own examples and add no new meaning for any parameter.

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?

States a specific verb and resource ('Returns du'as from a curated du'a corpus') with scope ('for a life context') and the accompanying metadata ('source and grading'). It clearly distinguishes itself from the Quranic/name-of-Allah siblings by virtue of being the du'a corpus tool, though it never names those siblings explicitly.

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?

Usage is implied by 'for a life context (e.g. anxiety, travel, gratitude)', which tells the agent the input shape but not when to prefer this over find_verses or get_quran_verse. The id-vs-context exclusivity and locale/audience selection rules live only in the schema, and no exclusions or alternatives are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_name_of_allahget_name_of_allahAInspect

Returns one of the 99 Names of Allah by number (1-99) or by name: Arabic, transliteration, meaning, reflection and Quranic references. Quote the Arabic exactly.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name input — Latin transliteration ('Al-Hakam'), Arabic ('الحكم'), or English meaning ('The Judge').
`locale`	No	Locale for meaning + reflection. Defaults to "en".
`number`	No	Number of the Name in the canonical list, 1-99.
`audience`	No	Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It usefully discloses the record contents and adds a real behavioral instruction ('Quote the Arabic exactly') that no structured field encodes. It does not disclose error behavior for an unmatched name/number or precedence when both keys are given.

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?

Two sentences, zero filler. The lookup keys and returned fields are front-loaded, and the quoting caution is short and actionable.

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?

With no output schema or annotations, the description compensates reasonably by enumerating the returned fields and the lookup modes, and the schema covers locale/audience semantics. It falls just short by omitting fallback/error behavior and mutual-exclusivity of the name and number inputs.

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 each of the four parameters (name, locale, number, audience) is already documented, establishing a baseline of 3. The description restates the number/name lookup and the returned fields but adds no syntax or precedence detail beyond the schema.

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?

States a specific verb (Returns) and a precise resource (one of the 99 Names of Allah) plus the two lookup keys (number 1-99 or name). It also enumerates the returned fields (Arabic, transliteration, meaning, reflection, Quranic references), which clearly separates it from find_verses, get_dua and get_quran_verse.

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 either/or phrasing 'by number (1-99) or by name' implies the two invocation paths, which is light usage guidance. However, there is no when-to-use context, no mention of the sibling tools, and no statement about what happens if both keys or neither key are supplied for a tool with zero required parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_quran_verseget_quran_verseAInspect

Returns one Quran verse by surah and ayah number: Tanzil Uthmani Arabic and Pickthall English, with citation. Quote the Arabic exactly; do not paraphrase either text.

ParametersJSON Schema

Name	Required	Description
`ayah`	Yes	Ayah (verse) number within the surah
`surah`	Yes	Surah number, 1-114
`locale`	No	Translation locale; defaults to "en" (Pickthall). Urdu and Indonesian translations are not yet available: "ur" and "id" return Pickthall English with a note.
`audience`	No	Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose meaningful traits: read-only retrieval, inclusion of a citation, and the strong constraint not to paraphrase or alter the text. It does not mention the locale fallback behavior for 'ur'/'id' (which lives only in the schema), so it stops short of fully covering behavioral edge cases.

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?

Two tight sentences with the core purpose front-loaded and the quoting constraint as a supporting instruction. Nothing is redundant or padded.

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 simple two-parameter lookup with 100% schema coverage and no output schema, the description adequately conveys what is returned and the key citation/quoting behavior. Minor gaps remain around the locale fallback and audience teaching-mode behavior, but those are covered by the schema.

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 surah, ayah, locale, and audience are already documented with ranges, enums, and fallback notes in the schema. The description merely references surah and ayah and adds no syntax or format meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Returns one Quran verse by surah and ayah number') and names the exact returned artifacts (Tanzil Uthmani Arabic, Pickthall English, citation). This cleanly separates it from the plural sibling find_verses, which implies search rather than lookup by exact reference.

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 phrasing 'by surah and ayah number' implies the tool is for exact-reference lookup, and the instruction to quote rather than paraphrase is a usage directive. However, it never explicitly says when to use this versus find_verses, nor any exclusions, so guidance remains inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesSep 29, 2026

Changedfind_verses1 field changed

addedInput schema / properties / audience

Added value: +{
+  "description": "Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.",
+  "enum": [
+    "curious",
+    "revert",
+    "practising"
+  ],
+  "type": "string"
+}

Changedget_dua4 fields changed

addedInput schema / properties / audience

Added value: +{
+  "description": "Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.",
+  "enum": [
+    "curious",
+    "revert",
+    "practising"
+  ],
+  "type": "string"
+}

changedInput schema / properties / context / description

Previous value: -"Life context to match against. Examples: 'anxiety', 'morning', 'travel', 'forgiveness', 'gratitude'."New value: +"Life context to match against. Examples: 'anxiety', 'morning', 'travel', 'forgiveness', 'gratitude'. Send this or id, not both."

addedInput schema / properties / id

Added value: +{
+  "description": "A du'a id taken from a related reference in an earlier response. Send this or context, not both.",
+  "pattern": "^[A-Za-z0-9-]{3,40}$",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

Changedget_name_of_allah1 field changed

addedInput schema / properties / audience

Added value: +{
+  "description": "Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.",
+  "enum": [
+    "curious",
+    "revert",
+    "practising"
+  ],
+  "type": "string"
+}

Changedget_quran_verse1 field changed

addedInput schema / properties / audience

Added value: +{
+  "description": "Optional: curious, revert or practising. Returns pre-authored teaching context where available; omit for the standard record.",
+  "enum": [
+    "curious",
+    "revert",
+    "practising"
+  ],
+  "type": "string"
+}

4 tool updatesSep 29, 2026
- First observedfind_verses
- First observedget_dua
- First observedget_name_of_allah
- First observedget_quran_verse

Related MCP Connectors

Quran A
io.github.pipeworx-io
Quran MCP — Al-Quran Cloud API.
Education & Learning Tools
442
Prayer Times A
io.github.pipeworx-io
Islamic prayer times & calendar MCP (Aladhan API). Keyless.
Location Services
442
Wasilah A
io.github.mumullickm
Prayer times, Qibla, Hijri calendar, 99 Names, Quran audio, Bangladesh offsets. English + Bengali.
Location Services Open Data
92
Muslim Prayer Reminder MCP A
io.github.tareq7
Production-ready Muslim prayer reminder MCP with astronomical precision and theological disclosure.
Location Services Calendar Management
511

Related MCP Servers

Azan-MCP
Education & Learning Tools
bartest5
A
license
B
quality
C
maintenance
An MCP server providing comprehensive Islamic utilities, including prayer times, azan, Hijri calendar, du'a, zakat, and the 99 Names of Allah.
Updated 2 months ago (2026-08-12 13:40 UTC)
34
MIT
Mashhor Quran MCP Server
Search Education & Learning Tools
mr-socialmedia
A
license
A
quality
C
maintenance
Provides read-only access to Quran data — reciters, surahs, full-text search, ayah retrieval, prayer times, live radio stations, and Hijri dates — so AI agents can answer Islamic content queries. Runs locally via stdio or remotely over stateless HTTP for Claude, ChatGPT, and other MCP clients.
Updated a month ago (2026-09-13 13:43 UTC)
8
ISC
quran-mcpofficial
Art & Culture Education & Learning Tools Research & Data
quran
F
license
Not graded
quality
D
maintenance
Provides canonical Quran text, translations, and tafsir commentary via MCP for accurate AI citation.
Updated a month ago (2026-09-15 08:02 UTC)
102
-
sanad-mcp
Search RAG Systems Art & Culture
ifte66
F
license
A
quality
C
maintenance
Serves a scholar-approved Islamic corpus of Qur'an and hadith passages to any MCP client with server-side refusal enforcement. Enables natural-language questioning, retrieval, policy checking, and honest corpus coverage reporting while preventing fabricated answers.
Updated a month ago (2026-09-04 20:31 UTC)
6
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

quran-mcpofficial

Glama MCP Gateway

Resources