AskSakina Islamic Knowledge MCP Server
# AskSakina Islamic Knowledge MCP Server
[](https://www.npmjs.com/package/@asksakina/islamic-knowledge-mcp)
[](./LICENSE)
[](https://registry.modelcontextprotocol.io/v0/servers?search=com.asksakina)
> **Specialist-AI-reviewed Islamic knowledge for AI agents.** Quranic verses, a curated du'a corpus, and the 99 Names of Allah — reviewed across the four mainstream Sunni schools (Hanafi, Maliki, Shafi'i, Hanbali) through AskSakina's structured specialist-AI review chain, which is not a substitute for a qualified scholar. Every response is wrapped in a presentation contract so agents cannot silently misrepresent the content.
**Architectural posture:** *"AskSakina ships records, agents ship answers."* The server is a reference library, not an advisor. Each response includes a `_sakina_meta` envelope with disclaimer, LLM directives, presentation contract, and educational context. What the calling agent does with the record is its responsibility: every response carries explicit instructions for handling it, but the server cannot make another AI follow them.
---
## What it provides
Four lookup tools, four learning-journey prompts and seven resources over the Model Context Protocol. Every record is sourced from AskSakina's main app (`asksakina.com`), so each MCP release matches what the public app surfaced when it was built.
| Tool | What it does |
|---|---|
| `get_quran_verse` | Verbatim Quranic verse lookup by surah:ayah |
| `get_dua` | Curated du'a corpus lookup by life context (anxiety, morning, travel, ...) |
| `get_name_of_allah` | One of the 99 Names by number (1–99) or string |
| `find_verses` | Quran verses by topic keyword, from AskSakina's thematic verse index |
| `understand_a_verse` (prompt) | Fetch one verse by surah and ayah, then present it with its teaching notes, if any |
| `explore_names_of_allah` (prompt) | Fetch one Name by number (1 if none is given), then present it and offer the next Name |
| `what_muslims_believe` (prompt) | Surah Al-Ikhlas, the Name Ar-Rahman, a reviewed overview of the articles of faith and the pillars, and Quran 2:256 |
| `first_steps_new_muslim` (prompt) | For a new Muslim, one step at a time (1-4): One God and His mercy, what has passed is forgiven, prayer step by step, your people |
| `sakina://about` (resource) | Read-once briefing — seven core directives plus three Gem-cleared dawah texts (Quran preservation, hadith grading, madhab attribution) |
| `sakina://learn/...` (resources, 2.5.0) | The six reviewed texts the two journeys read, served verbatim |
---
## Tools
### `get_quran_verse`
Verbatim Quranic verse lookup by surah:ayah. Returns the canonical AskSakina envelope with Arabic text, translation, surah name (Arabic + English), and the `quran` presentation contract, which instructs the agent not to paraphrase, to cite surah:ayah, and to label the translation "Translation of the Meaning".
**Parameters**
| Name | Type | Required | Notes |
|---|---|---|---|
| `surah` | `1`..`114` | yes | Surah number |
| `ayah` | `1`..`286` | yes | Ayah within the surah |
| `locale` | `'en'` \| `'id'` \| `'ur'` \| `'ar'` \| `'tr'` | no, defaults `en` | Translation language. `ar` returns the Arabic original with the Pickthall English alongside. Urdu, Indonesian and Turkish translations are not yet available (pending licences): `ur`, `id` and `tr` return Pickthall English, `translation_language: "en"` and a `translation_note` saying so |
**Example response (truncated)**
```jsonc
{
"_sakina_meta": {
"version": "1.0",
"content_type": "quran_verse",
"presentation_contract": {
"quran": {
"no_paraphrase": true,
"require_citation": "surah:ayah",
"translation_label": "Translation of the Meaning"
}
}
/* … */
},
"content": {
"surah": { "number": 2, "name_arabic": "البقرة", "name_english": "Al-Baqarah" },
"ayah": 186,
"arabic": "وَإِذَا سَأَلَكَ عِبَادِي عَنِّي فَإِنِّي قَرِيبٌ ۖ …",
"translation": "And when My servants ask you concerning Me — indeed I am near. …"
}
}
```
### `get_dua`
Returns du'as matching a life context (anxiety, grief, morning, travel, etc.). Context is resolved against canonical category slugs, an alias map, and tag dimensions. A natural phrase ("grief after losing my mother") also resolves: the server normalises it and matches known category, alias, tag and synonym words and a few multi-word phrases inside it, deterministically and without AI. `content.matched_by` says how it resolved. **Grief (WO#386):** a query that names the querier's own grief ("I lost my mother", "grief after losing my mother", "my father passed away", "bereaved") resolves to context `bereaved`; a funeral rite or the person who has died ("funeral", "dua for the deceased", "visiting my mother's grave") stays `deceased`. **Parents (WO#430):** a query that names a parent (mother, mum, mom, father, dad, parent, parents) together with a death word (late, dead, passed, grave, burial, janaza, janazah, cemetery, funeral, died, death, deceased, lost) takes this grief route and never returns `mothers` or `fathers`; "miss" with a parent and no death word returns only the du'as that suit a living or a deceased parent; a plain parent query ("my mother", "parents") is unchanged. A death word on its own, such as "grave", resolves to nothing. `bereaved` returns seven du'as ruled by the fiqh reviewer (Gem 4), in its order, with a `teaching_note` on the masculine forms in the Arabic, and always carries at least the soft support note. Crisis detection runs first, on the full raw input. Self-harm and abuse get separate blocks (`crisis_type`): the abuse block carries domestic-abuse lines and an abuse-specific directive. **On any hard crisis (self-harm or abuse) no du'as are returned**: `content_type` is `crisis_resource_only` and the crisis resource is the whole response. Each block lists 24/7 lines first and states the hours of any limited-hours line. **If the context contains a crisis keyword (matched against the main app's `detectCrisis` keyword list), the response includes a mandatory `crisis_resource` block** with the appropriate hotline and prosocial directive.
**Parameters**
| Name | Type | Required | Notes |
|---|---|---|---|
| `context` | `string` | one of `context` or `id` | Free-form life context |
| `id` | `string` | one of `context` or `id` | A du'a id taken from a `related` reference in an earlier response (WO#390) |
| `locale` | `'en'` \| `'id'` \| `'ur'` \| `'ar'` \| `'tr'` | no, defaults `en` | Du'a records are English for every locale; a crisis resource is in the request locale (2.2.1); with the locale omitted or `en`, a hard crisis resource is in the language of the matched crisis keyword (id, ur, ar or tr; 2.2.2) |
| `audience` | `'curious'` \| `'revert'` \| `'practising'` | no | From the user's own self-description only. Echoed as `teach.audience`; omitted, the teach block says `unknown` (2.2.0) |
| `limit` | integer 1 to 10 | no, defaults 3 | How many records a context lookup returns (2.2.0). The bereaved set and the abuse allowlist are always returned whole. Ignored with `id` |
| `offset` | integer, 0 or more | no, defaults 0 | How many records to skip before the page, for paging with `limit` (2.2.0). Ignored with `id` and on `bereaved` |
**Result shaping (2.2.0).** A context lookup returns `limit` records of the route's existing order (bundle order; Gem 4's fixed order on `bereaved`), starting at `offset`. When more follow the page, `content.total_available` gives the whole count, `content.truncated` is true, and `content.more` carries the note "N more du'as for this context; call get_dua with offset and limit to see them." The same note is in `CRITICAL_RULES`. `content.offset` is present when it is not 0. Every record of a category is reachable by paging.
**Example response (truncated)**
```jsonc
{
"_sakina_meta": {
"content_type": "dua_collection",
"presentation_contract": {
"hadith": { "require_grading": "per_record" /* true when every record is graded */ }
}
/* … */
},
"content": {
"context": "stress-anxiety",
"duas": [
{
"dua_block": "Arabic: …\nTransliteration: …\nTranslation: …\nOrigin: Quran 21:87\nSource: Quran 21:87\nGrading: Quranic",
"title": "Dua to Deal with Distress & Depression",
"arabic": "وَذَا ٱلنُّونِ إِذ ذَّهَبَ …",
"source": "Quran 21:87",
"grading": "Quranic",
"grading_status": "quranic",
"origin": "quran",
"quran_citation": "Quran 21:87"
},
{
"title": "Dua to Remove Sorrow & Grief:",
"source": "Source not recorded in AskSakina corpus",
"grading": "Not graded in AskSakina corpus",
"grading_status": "not_recorded"
/* … */
}
/* … */
],
"total_results": 3,
"total_available": 12,
"truncated": true,
"more": "9 more du'as for this context; call get_dua with offset and limit to see them.",
"grading_summary": { "quranic": 2, "graded": 0, "not_a_narration": 0, "not_recorded": 1 }
}
// crisis_resource block added if context triggers the crisis keyword list
}
```
**Grading status.** Every du'a record carries `grading_status`: `quranic` (the text is a Quranic verse or clause), `graded` (a hadith grading is recorded), `not_a_narration` (a general supplication, not a narration from the Prophet; it carries a `grading_directive` saying so), or `not_recorded` (the AskSakina corpus holds no grading for it). Most of the corpus is `not_recorded` today; the `Source` and `Grading` lines say so rather than implying a grading exists. Du'as whose Quranic reference has been verified carry `origin: "quran"` and a `quran_citation`, and their Arabic is the Tanzil Uthmani text resolved from AskSakina's scripture module at bundle time.
### `get_name_of_allah`
Look up by number (1–99) or string (transliteration, Arabic, or English meaning). Returns Arabic, transliteration, locale-aware meaning, reflection, and Quranic references.
**Parameters** — one of:
| Name | Type | Notes |
|---|---|---|
| `number` | `1`..`99` | Primary lookup |
| `name` | `string` | Transliteration, Arabic, or English meaning |
Plus optional `locale` (`tr` returns the English meaning and reflection).
**Example response (truncated)**
```jsonc
{
"_sakina_meta": { "content_type": "name_of_allah" /* … */ },
"content": {
"number": 29,
"arabic": "الحَكَم",
"transliteration": "Al-Hakam",
"meaning": "The Judge",
"reflection": "Allah is the absolute Judge…",
"quran_references": ["6:114", "13:41"]
}
}
```
### `find_verses`
Topic lookup beside `get_quran_verse`'s reference lookup (WO#386). The query is normalised and each word is matched to a theme of AskSakina's thematic verse index (anxiety, gratitude, patience, trust, grief, hope, forgiveness, morning, friday, ramadan, encouragement), by theme name or a fixed synonym list. Deterministic: no embedding, no AI call.
2.5.0 (WO#495) adds fifteen themes, each with its verses in a ruled order: companionship, family_and_marriage, hereafter, parents, night_and_rest, character, justice, protection, quran_and_knowledge, faith_and_guidance, prophets_and_creation, seasons, provision, healing and certainty. Companionship (loneliness) carries the soft support block, as grief does, and no teaching content. Healing carries one more directive: the verses are spiritual comfort and do not replace medical care. A query that carries an abuse word the crisis detector does not read alone ("abuse", "abusive", "violence" and their forms) reaches none of the fifteen and is answered as 2.4 answered it. Since 2.5.1 (WO#500), disclosure phrases built on those words ("abusing me", "abusive husband", "my father is violent", and Gem 3's phrases in Urdu, Arabic, Indonesian, Bengali and Persian) are crisis keywords: they return the abuse resource block before any theme.
Each verse carries `reference` (surah:ayah), `arabic` (the full ayah from the scripture module, Tanzil Uthmani, byte for byte), `translation` (full-ayah Pickthall, fetched as `get_quran_verse` fetches it), the surah names, and a `relevance_note` saying which theme lists it. The note is not commentary. If the upstream is unreachable, the Arabic is still served and `translation` is `null` with a note.
No match returns `content_type: "not_found"` with `verses: []`, `no_results: true` and the list of available themes, not an error. Crisis detection runs first, as on `get_dua`: any hard crisis (self-harm or abuse) returns `crisis_resource_only`, with no verses and no theme list.
**Parameters**
| Name | Type | Required | Notes |
|---|---|---|---|
| `query` | `string` | yes | Topic or keyword, e.g. `patience`, `grief`, `gratitude` |
| `limit` | `1`..`10` | no, defaults `5` | Number of verses |
| `locale` | `'en'` \| `'id'` \| `'ur'` \| `'ar'` \| `'tr'` | no, defaults `en` | Selects the in-country crisis resources. Translations are Pickthall English; `ur`, `id` and `tr` carry the parked-translation note |
### Resource: `sakina://about`
Read this resource **before** using the tools. It contains the seven core directives plus three Gem-cleared educational dawah texts. Most MCP clients fetch it automatically the first time they connect.
### Server `instructions` (2.2.0)
The initialize result carries `instructions` (1,529 characters, under the 1,801 limit): the quoting and teaching rules, the da'wah adab block ruled on 20 Oct 2026 (verbatim), and the open-door line with its conditions (only on the user's interest in Islam itself, at most once per conversation, never in distress, never as a condition of an answer, never after a decline). A client that surfaces `instructions` gives its model these rules once per session; the per-response rules in `_sakina_meta.llm_directives` apply either way.
### Teaching (2.2.0, "teach, don't hand off")
Where a teaching entry exists for a record (`src/teach/entries.ts`; six records today), the record carries a `teach` block and a `related` list, with or without `audience`. The directives give the teaching order: quote the record first, exactly (Arabic, translation, source, grading); then explain only from the teach block, as context from AskSakina's notes, not tafsir or a ruling; where the notes end, say so and point to a recognised tafsir or a qualified scholar; offer the reflection question verbatim without answering it; offer at most one related next step. Nothing attaches under a support block, on a grief route or on a crisis response, and the directives tell the agent to quote records only once the user has disclosed distress, grief or crisis. Where no teach block is supplied, the agent may explain only from the record's own supplied fields, attributed to AskSakina's notes, then hand over the same way.
### Prompts: learning journeys (2.4.0)
Two prompts, for clients that show MCP prompts (for example as slash commands). Each returns one user message that tells the agent to call one tool, then to present the response by the rules that response already carries (`_sakina_meta.llm_directives.CRITICAL_RULES` and `presentation_contract`, which hold the teaching order whenever a teach block is served) and by the server's da'wah adab, quoted verbatim. A prompt adds no religious content: everything the user sees comes from the tool's record and its Gem-approved teach entry, if one exists.
| Prompt | Arguments | The tool it calls | Next step |
|---|---|---|---|
| `understand_a_verse` | `surah` (1-114), `ayah` (1-286), both required | `get_quran_verse` | the teach block's own related step, if any |
| `explore_names_of_allah` | `number` (1-99), optional; 1 if none is given | `get_name_of_allah` | Name `number + 1`, offered once (none after 99) |
- Arguments are strings of digits, checked before the prompt runs; anything else is refused with `-32602` and the value is not echoed. Whether an ayah exists in its surah is answered by the tool (`not_found`), as for a direct call.
- If a response carries a `crisis_resource` block (crisis or soft support), the message tells the agent to follow that block's directive and add nothing: no reflection question and no next step.
- Prompt arguments are never logged or counted. `/stats` counts only how many times each prompt was fetched, by name.
### Prompts: the two journeys (2.5.0)
| Prompt | Arguments | What it asks the agent to do |
|---|---|---|
| `what_muslims_believe` | `audience` (`curious`, `revert` or `practising`), optional; `curious` if none is given | Read `sakina://about`; fetch 112:1-4, Name 1, the resource `sakina://learn/what-muslims-believe` and 2:256; follow-ups only from those records; one next step; the open-door line at most once, never after a crisis block or distress |
| `first_steps_new_muslim` | `step` (`1` to `4`), optional; `1` if none is given | One step per fetch, always with `audience` `revert`: 1 the shahada (without asking the user to say it), 112:1-4, Names 1 and 2; 2 8:38, the resource on forgiveness, Name 34, 39:53 and the du'a Sahih al-Bukhari 744 (`get_dua` id `D00234`); 3 wudu and the first prayer, 1:1; 4 finding a community. No open door. |
- Arguments are checked before the prompt runs; anything else is refused with `-32602` and the value is not echoed.
- The resources (`sakina://learn/what-muslims-believe`, `sakina://learn/first-steps#shahada`, `#forgiven`, `#wudu`, `#first-prayer`, `#community`) are built by script from the app's own reviewed seed modules and the Gems' rulings (`scripts/wo495-learn-content.ts`); the build fails if the committed text differs.
- **Notes for a new Muslim (`audience_note`).** With `audience: "revert"`, six records carry AskSakina's note for a new Muslim (112:1, 1:1, Names 1, 2 and 34, and the du'a D00234), with its own citations and a `note_block` to quote exactly. It is withheld wherever teach is withheld (crisis, support block, grief, non-English locale).
---
## Response envelope
Every tool returns the same shape:
```jsonc
{
"_sakina_meta": {
"version": "1.0",
"source": "AskSakina Islamic Knowledge Server (asksakina.com)",
"content_type": "quran_verse" | "dua_collection" | "name_of_allah" | "not_found" | "crisis_resource_only",
"disclaimer": "AskSakina provides curated Islamic reference content for educational purposes. …",
"llm_directives": { "CRITICAL_RULES": ["…"] },
"presentation_contract": {
"quran": { "no_paraphrase": true, "require_citation": "surah:ayah" /* … */ },
"hadith": { "require_grading": true, "require_source": true /* … */ },
"name_of_allah": { "no_paraphrase_arabic": true /* … */ }
},
"educational_context": "…"
},
"content": { /* tool-specific record; a record with a teaching entry also carries "teach" and "related" (2.2.0) */ },
// get_dua and find_verses, when crisis keywords detected:
"crisis_resource": { "level": "hard" | "soft", "crisis_type": "self-harm" | "abuse", "locale": "…", "directive": "…", "text": "…" }
}
```
The envelope is the contract: `_sakina_meta.presentation_contract` tells the agent how to render the record, `disclaimer` tells the agent what claims it cannot make on its own authority, and `crisis_resource` asks the agent to put the crisis resource before everything else when a user's distress crosses a safety threshold. These are instructions to the client AI; the server cannot force another AI to follow them.
### Structured output (2.4.2)
Each tool publishes an `outputSchema` and returns the envelope twice: as `structuredContent` (an object) and as the text content (the same envelope as JSON text, unchanged from earlier releases). The two always hold the same data. The schema per tool (`src/contracts/output-schemas.ts`):
| Tool | `content_type` | `content` |
|---|---|---|
| `get_quran_verse` | `quran_verse`, `not_found` | the verse (surah number and names, ayah, `arabic_text`, `translation`, `translation_source`, `translation_language`; optional `teach`, `related`), or `{ requested, reason }` |
| `get_dua` | `dua_collection`, `not_found`, `crisis_resource_only` | `{ context, matched_by, duas[], total_results, total_available, truncated, grading_summary }`, or `{ requested, reason }`, or `{ requested, withheld, reason }` |
| `get_name_of_allah` | `name_of_allah`, `not_found`, `crisis_resource_only` | the Name (`name_block`, `number`, `arabic`, `transliteration`, `english_meaning`, `reflection`, `quranic_references`; optional `teach`, `related`), or `{ requested, reason }`, or `{ requested, withheld, reason }` |
| `find_verses` | `verse_collection`, `not_found`, `crisis_resource_only` | `{ query, matched_themes[], verses[], total_results, no_results }`, or the no-match shape (`available_themes`), or `{ requested, withheld, reason }` |
Every response carries `_sakina_meta` (`version`, `source`, `content_type`, `disclaimer`, optional `disclaimer_locale`, `llm_directives.CRITICAL_RULES`, `presentation_contract`, `educational_context`) and, where a crisis or soft support block applies, `crisis_resource` (`level`, optional `crisis_type`, `locale`, `directive`, `text`). Every object is open: a field added in a later release does not fail a client that validates.
---
## Quick start
### Run via npx (no install)
```bash
npx -y @asksakina/islamic-knowledge-mcp --stdio
```
With `--stdio` the package speaks MCP over stdin/stdout; wire it into any MCP client. Without the flag it starts the Streamable HTTP server on `$PORT` (default 3030, `POST /mcp`, `GET /health`), as the hosted endpoint runs. Before 2.1.0 the `sakina-mcp` command exited without starting either (WO#444).
### Connect via remote streamable HTTP
```
https://sakina-mcp.fly.dev/mcp
```
For agents that prefer a hosted endpoint over a local subprocess. Same tools, same envelope, same rate limits.
### Claude Desktop
Add to `~/Library/Application Support/Claude/claude_desktop_config.json` (macOS) or `%APPDATA%/Claude/claude_desktop_config.json` (Windows):
```jsonc
{
"mcpServers": {
"sakina": {
"command": "npx",
"args": ["-y", "@asksakina/islamic-knowledge-mcp", "--stdio"]
}
}
}
```
Restart Claude Desktop. The four tools and the `sakina://about` resource appear in the tool picker.
### Cursor
Add to `~/.cursor/mcp.json` (or workspace `.cursor/mcp.json`):
```jsonc
{
"mcpServers": {
"sakina": {
"command": "npx",
"args": ["-y", "@asksakina/islamic-knowledge-mcp", "--stdio"]
}
}
}
```
### VS Code (with an MCP-aware extension)
Add to `.vscode/mcp.json` in your workspace:
```jsonc
{
"servers": {
"sakina-islamic-knowledge": {
"command": "npx",
"args": ["-y", "@asksakina/islamic-knowledge-mcp", "--stdio"]
}
}
}
```
### Generic MCP client over remote HTTP
```jsonc
{
"mcpServers": {
"sakina": {
"type": "streamable-http",
"url": "https://sakina-mcp.fly.dev/mcp"
}
}
}
```
---
## Use cases
The MCP server is designed for any agent or application that needs curated Islamic source material, returned with explicit instructions to quote it exactly rather than paraphrase it.
- **Build an Islamic chatbot with cited references where recorded.** Pipe `get_quran_verse` and `get_dua` into your conversation flow; the presentation contract instructs the agent to quote exactly and keep gradings attached, and each response states its content type and, for du'as, each record's grading status.
- **Add prayer-time-aware spiritual content to your agent.** Combine the Quranic and du'a tools with a prayer-time API to surface Allah's words at the right moment of the day.
- **Recommend du'as based on user context.** The crisis-keyword filter in `get_dua` handles the dangerous edge cases (self-harm language, abuse) so your assistant is directed not to reply with a generic du'a to a safety-critical message.
- **Answer questions about the 99 Names.** `get_name_of_allah` returns the canonical Arabic, transliteration, meaning, and reflection — plus Quranic references — for both number-based and name-based lookups.
- **Stay theologically inclusive.** The server is designed not to present a contested ruling as the universal answer.
---
## Content integrity
New and changed content is reviewed by AskSakina's "Gem" specialist-AI review chain before shipping. Four of its reviewers gate every Islamic-knowledge release:
1. **Quran & Translation Verification.** Ayah accuracy, surah/ayah citation correctness, hadith grading, source review.
2. **Fiqh Diversity (Multi-Madhab).** Cross-school accuracy, no single-madhab framing on contested topics, inclusive language.
3. **Islamic Psychology & Pastoral Care.** Comfort window safety, crisis filter coverage, no guilt-based motivation.
4. **Explorer / New-to-Islam Accessibility.** Glossing of Arabic terms for non-Muslim audiences, plain-English fiqh, zero-assumed-belief reflections.
Architectural behaviours implemented in code:
- The Unicode prophet salutation (U+FDFA, ﷺ) is replaced with `(peace be upon him)` at every data-loader boundary. The response builder rejects any output containing the symbol.
- Each du'a record carries a `grading_status` (`quranic`, `graded`, `not_a_narration`, `not_recorded`). The `hadith` presentation contract sets `require_grading: true` only when every returned record is graded or Quranic, and `"per_record"` otherwise, so the envelope never claims a grading the data does not hold.
- Crisis keyword detection runs on every `get_dua` request — the same keyword list used by the main app's safety gate.
**Sacred Use License.** This server is distributed under a Sacred Use License (see [LICENSE](./LICENSE)). Permitted uses centre on dawah, education, personal worship, and respectful integration into Muslim-serving applications. The license forbids monetisation that frames Islamic knowledge as scarce or paywalled. A public summary of the license terms lives at `https://www.asksakina.com/en/mcp`.
**Privacy.** See [Privacy & Analytics](#privacy--analytics).
---
## Running locally for development
```bash
cd mcp-server
npm install
npm run bundle-data # snapshot data from main repo into data/
npm run typecheck # tsc --noEmit
npm run start # HTTP server on :3030 via tsx
npm run test:tools # exercise each tool, prints sample JSON
# Or build + run from compiled output:
npm run build # tsc -> dist/, postbuild adds shebang + dist/package.json
npm run start:dist # node dist/server.js
```
`POST /mcp` accepts standard MCP JSON-RPC 2.0. `GET /health` returns `{ "status": "ok", "name", "version" }`.
## Rate limiting
Default: **60 requests per minute per IP**.
- `UPSTASH_REDIS_REST_URL` + `UPSTASH_REDIS_REST_TOKEN` set → distributed Upstash Redis fixed window.
- Otherwise → in-memory token bucket, per process.
Responses include `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`. A 429 with code `-32029` is returned on exceed.
## Authentication
v1 ships unauthenticated. An optional `X-Sakina-App-Id` header is accepted but not enforced or logged in v1. This becomes required in v2.
## Privacy & Analytics
This service operates with an aggregate-only data model (WO#360; daily totals WO#456; teaching counters WO#477). For each tool, the server maintains a running count of calls by outcome (`ok`, `not_found`, `error`), the summed handler time to report operational averages, and the number of responses that carried a teaching block. Across all tools it also counts how many calls carried each value of the optional `audience` argument (`curious`, `revert`, `practising`, `unknown`, or none), and how many times each learning prompt was fetched. These are totals only, reported via the `/stats` endpoint.
- **No persistent tracking:** No per-request logs or client identifiers are written to disk or any database by the application.
- **Ephemeral IP handling:** Client IP addresses are used only to enforce the rate limit. Each is held as a rate-limit key in Upstash Redis for the rate-limit window (60 seconds), then expired. If Upstash is unavailable, the in-memory fallback holds it in process memory for the same window, then discards it. Raw IP addresses are never persisted by the application, and never written to logs.
- **No payload logging:** Request parameters (such as context values, verse references, Name numbers, prompt arguments or locale) and response payloads are never captured or logged. The one argument that is counted is audience, and only as a tally of its four fixed values plus "none"; the value itself is never stored with the call, the tool, or anything else.
- **Since-start counters:** The totals `/stats` reports under `by_tool` exist only in RAM and are reset when the server process restarts.
- **Daily totals on the server's own disk:** On the hosted server, the number of calls to each tool on each UTC day, by outcome (`ok`, `not_found`, `error`), their summed handler time, the number that carried a teaching block, the tally of `audience` values, and the number of fetches of each learning prompt are written to the server's own disk so that they survive restarts. They are kept for at most 90 days; older days are deleted. They contain no IP addresses, user agents, client identifiers, times of individual calls, parameters or payloads, and cannot be linked to any request or person. They are written only where `MCP_USAGE_DIR` is set: a local `npx` or `--stdio` run writes nothing.
- **Nothing per person:** No counter is kept per client, session, user or conversation. The teaching, audience and prompt counters are the same kind of number as the per-tool call counts: one running total across every caller.
*Regulatory Note (UK GDPR): Because nothing identifiable is held beyond the rate-limit window, there are no records that could be accessed or erased. Note that while the application itself does not persist personal data, our infrastructure provider (Fly.io) transiently processes IP addresses at the edge layer for standard network routing and platform security.*
### `/stats` endpoint
Authenticated summary endpoint:
```bash
curl -H "Authorization: Bearer $MCP_STATS_TOKEN" https://sakina-mcp.fly.dev/stats
```
Requires the `MCP_STATS_TOKEN` env var to be set (otherwise the endpoint returns 503 and refuses to serve unauthenticated). Token comparison is constant-time.
Payload shape:
```json
{
"privacy": "aggregate-only counters; no per-request records, no IPs, no user-agents, no client identifiers, no geolocation, no params beyond a tally of audience values, no payloads; since-start totals reset on restart; daily totals (per tool: ok, not_found, error, summed duration, teach served; plus audience tally and prompt fetches by name) kept on the server's own disk for at most 90 days",
"since": "2026-09-25T…",
"total_requests": N,
"by_tool": {
"get_quran_verse": { "total": N, "ok": N, "not_found": N, "error": N, "avg_response_ms": N, "teach_served": N },
"get_dua": { "total": N, "ok": N, "not_found": N, "error": N, "avg_response_ms": N, "teach_served": N },
"get_name_of_allah": { "total": N, "ok": N, "not_found": N, "error": N, "avg_response_ms": N, "teach_served": N },
"find_verses": { "total": N, "ok": N, "not_found": N, "error": N, "avg_response_ms": N, "teach_served": N }
},
"audience": { "curious": N, "revert": N, "practising": N, "unknown": N, "absent": N },
"prompts": { "understand_a_verse": N, "explore_names_of_allah": N, "what_muslims_believe": N, "first_steps_new_muslim": N },
"rate_limiter": {
"state": "upstash",
"upstash_configured": true,
"upstash_failures": 0,
"last_failure": null,
"last_failure_at": null,
"last_success_at": "2026-09-25T…",
"startup_check": "Upstash reachable (PING ok, 12 ms); state: upstash"
},
"basmala_prefix_mismatch": 0,
"daily": {
"retention_days": 90,
"days": [
{ "date": "2026-10-12", "total": N,
"by_tool": { "get_dua": { "total": N, "ok": N, "not_found": N, "error": N, "avg_response_ms": N, "teach_served": N }, … },
"audience": { "curious": N, "revert": N, "practising": N, "unknown": N, "absent": N },
"prompts": { "understand_a_verse": N, "explore_names_of_allah": N, "what_muslims_believe": N, "first_steps_new_muslim": N } }
]
}
}
```
`daily` lists the stored days, newest first, with today's not-yet-written calls included; it is `null` when `MCP_USAGE_DIR` is unset, and the `privacy` line then names the in-memory counters only ("aggregate-only in-memory counters, including teach-served per tool, a tally of audience values and prompt fetches by name; … resets on restart").
`teach_served` counts responses that carried a teach block (WO#488). `audience` tallies the optional `audience` argument of every tool call by its four fixed values, with `absent` for a call that sent none; it is one total across all tools, never joined to a tool, a call or a time finer than the UTC day. `prompts` counts fetches of each learning prompt by name; prompt arguments are never read.
`rate_limiter.state` is `upstash` (Upstash answering), `degraded` (Upstash configured but failing: requests are limited by the in-memory fallback, never allowed through) or `memory` (Upstash not configured). Failure reasons carry the HTTP status or error, never a client IP. `basmala_prefix_mismatch` counts ayah-1 texts from the upstream that started with neither recorded basmala form and were served unchanged. It is an aggregate count only; the log line for it carries no verse reference.
### One-time setup on Fly
```bash
fly secrets set MCP_STATS_TOKEN=$(openssl rand -hex 32)
fly deploy
```
The server writes one thing to the `/data` volume that `fly.toml` mounts: the daily totals, one file per UTC day in `/data/usage` (`MCP_USAGE_DIR`), written every 5 minutes and when Fly stops the machine. `LOG_DIR` (`/data/logs`) has been unused since WO#360.
## Data sources
| Tool | Source |
|---|---|
| `get_quran_verse` | **English (2.1.0, WO#444):** AskSakina's corrected Pickthall, bundled as `data/pickthall.json` from the app's `public/quran/en.pickthall` (all 6,236 verses, the WO#442 corrections against the 1930 text included, no verse-final punctuation, as the app's reader shows it), for every locale: `ur` and `id` carry a note (their translations are parked pending licences; 1.4.1). **Arabic and surah names:** `alquran.cloud`, fetched at runtime (Tanzil-derived Uthmani). A leading byte-order mark is removed. The upstream also prefixes the basmala to ayah 1 of each surah except 1 and 9. Per Gem 2 (the basmala is part of ayah 1 only at 1:1), that exact prefix is removed from ayah 1 of surahs 2–8 and 10–114, matched against the two byte forms the upstream sends. The rest of the ayah is served byte for byte. An unrecognised start is served unchanged and counted in `/stats` (`basmala_prefix_mismatch`). Everything is fetched verse by verse (`/ayah/{surah}:{ayah}`). Saheeh International is not served (removed in 1.2.0, WO#245). Cached in process for 24 h per verse + edition. |
| `get_dua` | AskSakina's du'a corpus (440 entries at 2.1.0), snapshotted from `../src/data/duas` into `data/duas.json` by `npm run bundle-data`. Du'as with a verified Quranic reference take their Arabic from the scripture module (`../src/lib/scripture`, Tanzil Uthmani) at the same step. |
| `get_name_of_allah` | AskSakina's 99 Names, snapshotted from `../src/lib/data/99-names` by `npm run bundle-data`. |
| `find_verses` | AskSakina's thematic verse index (`../src/lib/data/thematic-verses`), snapshotted into `data/thematic-verses.json` by `npm run bundle-data`. Only each verse's reference and themes are taken from the index; the Arabic comes from the scripture module at the same step, and the Pickthall translation from the bundled `data/pickthall.json` (2.1.0; the surah names still come from `alquran.cloud` at runtime, same cache as `get_quran_verse`). |
The du'a and Names data are snapshots of the main app's data files, so any update to them lands here on the next `npm run bundle-data` (the deploy workflow runs it). A published package carries the snapshot taken when it was built.
---
## Out of scope for v1
Per the Phase 3 planning doc:
- Semantic search / `search_islamic_guidance` — needs a Gem-reviewed eval set. (`find_verses` is an index lookup, not semantic search.)
- `explain_islamic_concept` — directly conflicts with CLAUDE.md's "AI never gives spiritual/fiqh advice" rule until an Architect-level ruling is made.
- `get_pastoral_guidance` — Gem 3's framing depends on AskSakina-controlled surface; cannot ship via MCP without a separate review.
- `check_halal_ingredient` — blocked on WO#61 restoration.
- HMAC signing enforcement — v1 accepts but ignores the `X-Sakina-App-Id` header.
---
## Deployment
Self-contained at publish time — `npm run bundle-data` snapshots the du'a corpus, the 99 Names, and the canonical safety modules from the main AskSakina monorepo into `data/` and `src/safety/_synced/`. The compiled `dist/` plus the bundled `data/` directory have no runtime dependency on the main app.
`bundle-data` runs automatically via a `prebuild` script (WO#138), so `npm run build` is self-contained on a fresh checkout — no manual bundling step required. The `src/safety/_synced/` directory IS committed to git so any drift from the main-app safety modules shows up in `git diff` between commits.
`docker build` does NOT run `prebuild` (it only copies the `mcp-server/` directory, not the monorepo). Run `npm run bundle-data` on the host before `docker build` so `data/` is populated. The same applies if you build from a fresh clone — `npm install && npm run bundle-data` before `docker build`.
### CI deploy (canonical — WO#249)
All MCP releases go through the **`MCP Server Deploy`** GitHub Actions workflow
(`.github/workflows/mcp-deploy.yml`) — no developer machine holds `flyctl` or npm
auth. The Architect triggers it from the repo **Actions** tab
(`workflow_dispatch`) with two boolean inputs:
- **`deploy_fly`** (default `true`) — build + `flyctl deploy` to `sakina-mcp.fly.dev`.
- **`sync_mirror`** (default `true`) — push the built package to the public mirror
(github.com/yserrag/asksakina-mcp) and tag `v<version>` there. The mirror's own
workflow then publishes `@asksakina/islamic-knowledge-mcp` to npm with trusted
publishing and provenance (WO#444); this repository holds no npm token.
The job runs the full Gem 10 runbook on `main`: `npm ci` → `npm run bundle-data`
(load-bearing) → `flyctl deploy` → poll `/health` → **live Pickthall byte-check on
2:255 and 9:129** → live Dhun-Nun check → rate-limiter probe (warn only) → **live publish guards** → agent evals (warn only; after the guards since WO#386, so the blocking guards get the rate-limit budget first) → mirror sync and tag (the mirror publishes). The
byte-check runs the MCP `initialize` handshake + `tools/call get_quran_verse`
against the live endpoint: `"save Him"` (Pickthall) passes; `"except Him"` (Saheeh
International) or an unreachable `/mcp` **fails the job before the mirror sync**,
dumps `flyctl status` + logs, and prints the manual rollback commands. 9:129 must
read "There is no God save Him", which only the bundled corrected text carries.
Secrets `FLY_API_TOKEN` and `ASKSAKINA_MCP_DEPLOY_KEY` live in repo settings and
are never echoed.
> Automated rollback-to-previous-image is the Gem 10 end-state but is a deferred
> follow-up: the current live image is itself broken, so there is no known-good
> image to auto-restore yet. The first runs are fail-loud + manual rollback only.
### Fly.io (manual / break-glass)
Prefer the CI workflow above. These commands are the underlying mechanics, for a
machine that already has `flyctl` auth:
```bash
cd mcp-server
fly launch # first time only — picks up fly.toml
fly secrets set \
UPSTASH_REDIS_REST_URL=... \
UPSTASH_REDIS_REST_TOKEN=...
npm run bundle-data # load-bearing: docker build copies host data/
fly deploy
fly status
curl https://<app>.fly.dev/health
```
Production app: `sakina-mcp.fly.dev`. App `sakina-mcp`, region `lhr`, internal port 3030, force HTTPS, healthcheck on `/health` every 30 s, auto-stop on idle, 1 shared CPU, 256 MB RAM.
### Post-deploy verification and rollback
After every `fly deploy`, byte-check one Quran verse from the live endpoint against the locked Pickthall table (`docs/wo-cert/si-pickthall-LOCKED-final.json`) to confirm the translation edition is Pickthall, not Saheeh International:
```bash
curl -s https://sakina-mcp.fly.dev/mcp ... # call get_quran_verse for a known ref
# compare the returned translation to the locked Pickthall text for that ref
```
If the byte-check fails (SI text served, or the translation does not match Pickthall), **roll back first, diagnose second**. Immediately redeploy the previous image before any further investigation or fix:
```bash
fly releases --app sakina-mcp # find the last-good release / image
fly deploy --app sakina-mcp --image <previous-image-ref>
```
Do not attempt a forward fix on a live SI regression — restore the known-good image, confirm the byte-check passes on it, then diagnose the bad build offline.
### Local container test
```bash
docker compose up --build
curl http://localhost:3030/health
```
### Other targets
The package is just a Node.js HTTP server, so it runs on any platform that takes a Dockerfile or a Node process: Railway, Render, a small VPS, Cloudflare Workers (with the streamable-http transport), Vercel Functions (with a small adapter). The in-memory rate limiter falls back gracefully when Upstash isn't configured.
---
## npm publishing
Publishing goes through the **`MCP Server Deploy`** workflow (see [CI deploy](#ci-deploy-canonical--wo249)) with `publish_npm: true` — the Architect triggers it from the Actions tab; `NPM_TOKEN` lives in repo settings. The manual equivalent (break-glass, needs local npm auth):
```bash
cd mcp-server
npm login # to the @asksakina org
npm publish --access public
```
`prepublishOnly` runs `bundle-data` → `build` → `test:tools` so the published tarball always contains fresh data and a clean build. The `files` field whitelists `dist/`, `data/`, `README.md`, `LICENSE`, and `.mcp/server.json`.
Verify the published tarball with `npm pack --dry-run` first to see what would ship.
## MCP Registry submission
`mcp-server/.mcp/server.json` declares AskSakina's identity for the official MCP Registry:
- Server name: `com.asksakina/islamic-knowledge`
- Package: `@asksakina/islamic-knowledge-mcp` (npm, stdio transport)
- Remote: `https://sakina-mcp.fly.dev/mcp` (Streamable HTTP)
Publishing flow: the **MCP Registry Publish** GitHub Actions workflow (`.github/workflows/mcp-registry-publish.yml` in the main repository, manual dispatch). It checks that `server.json`, `package.json` and npm agree, then runs:
```bash
mcp-publisher login dns --domain asksakina.com --private-key <KEY> # or: login http
mcp-publisher publish .mcp/server.json
curl "https://registry.modelcontextprotocol.io/v0/servers?search=com.asksakina"
```
Domain proof for `com.asksakina` is an Ed25519 key: the public half in a DNS TXT record on `asksakina.com` (`v=MCPv1; k=ed25519; p=<base64>`, since May 2026) or at `https://asksakina.com/.well-known/mcp-registry-auth`; the private half in the repository secret `MCP_REGISTRY_PRIVATE_KEY`.
### Smithery re-publish (after a version bump)
Three places carry the version — all bumped together:
1. `package.json` (`"version"`)
2. `mcp-server/.mcp/server.json` (top-level `version` **and** `packages[0].version`)
3. `mcp-server/src/server.ts` (`SERVER_VERSION` constant — surfaces in `/health` and `/.well-known/mcp/server-card.json`)
Re-publish checklist when bumping:
```bash
cd mcp-server
npm run typecheck && npm run test:tools && npm run test:analytics
npm run bundle-data
npm publish # npm registry
mcp-publisher publish .mcp/server.json # MCP Registry
fly deploy # Smithery scanner picks up the new card via /.well-known/mcp/server-card.json
```
Smithery auto-scans `/.well-known/mcp/server-card.json` and re-indexes within a few minutes — no manual Smithery API call needed.
---
## Links
- **Web:** [asksakina.com](https://www.asksakina.com)
- **MCP showcase:** [asksakina.com/en/mcp](https://www.asksakina.com/en/mcp)
- **MCP registry:** [registry.modelcontextprotocol.io — com.asksakina/islamic-knowledge](https://registry.modelcontextprotocol.io/v0/servers?search=com.asksakina)
- **npm:** [npmjs.com/@asksakina/islamic-knowledge-mcp](https://www.npmjs.com/package/@asksakina/islamic-knowledge-mcp)
- **Source:** [github.com/yserrag/asksakina-mcp](https://github.com/yserrag/asksakina-mcp) (mirror of `mcp-server/` in the main repository)
- **Issues / questions:** [github.com/yserrag/asksakina-mcp/issues](https://github.com/yserrag/asksakina-mcp/issues)
TDQS
Scored across 4 tools
Each tool targets a clearly distinct resource: a specific verse by reference (get_quran_verse), a du'a by life context (get_dua), a Name of Allah (get_name_of_allah), and thematic verse search (find_verses). The exact-reference lookup vs. keyword search distinction is clear from the descriptions.
Three tools use the get_<noun> pattern (get_quran_verse, get_dua, get_name_of_allah) consistently, while find_verses uses a search verb instead. This is a minor, sensible deviation but slightly breaks the uniform pattern.
Four tools is a lean but reasonable surface for a focused Islamic knowledge server. It is on the thin side and could accommodate a few more operations, but nothing feels redundant.
Core Quran, du'a, and Names-of-Allah access is covered, but an Islamic knowledge domain typically includes hadith and tafsir, which are notably absent. The existing surface works but has recognizable gaps.