Muslim Prayer Reminder MCP

Name: Muslim Prayer Reminder MCP
Author: tareq7

Server Details

Production-ready Muslim prayer reminder MCP with astronomical precision and theological disclosure.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 21 days
Last Tested: 2026-09-26 21:32
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: tareq7/muslim-prayer-mcp
GitHub Stars: 1
Server Listing: Muslim Prayer Reminder MCP

TDQS

A4.2/5.0

Scored 2026-09-18 06:40 across 5 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: configuring preferences, retrieving today's times, checking the next prayer, checking if a prayer is due, and reading preferences. No overlap or ambiguity exists among the five tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., configure_*, get_*), with clear action and object. The pattern is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a prayer reminder service, covering configuration, retrieval of times, status checks, and preference reading without unnecessary bloat or missing essentials.

Completeness4/5

The tool set covers the core workflow: configuration, daily times, next prayer, and due status. A minor gap is the lack of a method to retrieve prayer times for dates other than today, but this is not a critical omission for a reminder-focused server.

Available Tools

5 tools

configure_prayer_preferencesConfigure User Prayer PreferencesA

Idempotent

Inspect

Configures prayer calculation parameters, location behavior (fixed or auto_travel), madhab, reminder mode, and notification language in persistent storage.

ParametersJSON Schema

Name	Required	Description
`locale`	No	Language for reminder text: en or ar
`madhab`	No	Jurisprudential Asr shadow calculation: Shafi or Hanafi
`userId`	Yes	Unique user identifier
`enabled`	No	Whether prayer reminders are enabled
`timezone`	No	IANA timezone identifier (e.g. Asia/Riyadh, Europe/London)
`fixedCity`	No	Predefined city name for fixed location (e.g. Riyadh, London)
`locationMode`	No	Location strategy: auto_travel or fixed
`reminderMode`	No	Reminder display policy: prayer_window, exact_window, persistent
`fixedCoordinates`	No	Fixed geographical coordinates
`highLatitudeRule`	No	High latitude twilight adjustment rule
`calculationMethod`	No	Islamic prayer calculation authority
`minuteAdjustments`	No	Custom per-prayer minute offsets (-60 to +60)
`exactWindowMinutes`	No	Duration in minutes for exact_window mode

Output Schema

ParametersJSON Schema

Name	Required	Description
`success`	Yes	Whether configuration succeeded
`preferences`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already convey non-readonly, idempotent, and non-destructive behavior, so the description's added 'persistent storage' context is useful but not extensive. It does not disclose overwrite semantics or whether omitted fields are preserved, but it does not contradict the annotations.

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?

A single, front-loaded sentence that states the verb and resource first and then lists the configurable dimensions in a compact list. Every word adds information, and it is appropriately sized for the tool's scope.

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?

The tool is complex (13 parameters, nested objects, enums), but the input schema covers every parameter and an output schema exists, so the description does not need to repeat return or parameter details. It adequately frames purpose and persistence, though it could mention that only userId is required and omitted fields likely remain unchanged.

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?

With 100% schema description coverage, the schema already documents each of the 13 parameters. The description adds a high-level grouping of parameters into categories and names madhab, reminder mode, and notification language, but provides no per-parameter meaning 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?

The description names a clear action ('configures'), a specific resource (user prayer preferences), and enumerates the domains it affects: calculation parameters, location behavior, madhab, reminder mode, and notification language. This makes it easy to distinguish from the get_* siblings as the write/preference-update tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The verb 'configures' plus 'persistent storage' clearly signals this is the mutation tool, while sibling names like get_prayer_preferences and get_prayer_status cover read-only retrieval. It does not explicitly state exclusions or when not to use it, but the read/write split provides clear context.

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

get_next_prayerGet Upcoming Prayer and CountdownA

Read-onlyIdempotent

Inspect

Returns the immediate next prayer name, scheduled time, authority calculation method, and remaining countdown in minutes. MANDATORY: The LLM must always explicitly disclose to the user which calculation authority method was used and why it was selected (see authorityNotice in response).

ParametersJSON Schema

Name	Required	Description
`madhab`	No	Optional Asr shadow jurisprudence override (Shafi or Hanafi)
`latitude`	No	Optional explicit latitude override
`timezone`	No	Optional IANA timezone override
`longitude`	No	Optional explicit longitude override
`calculationMethod`	No	Optional calculation authority override (auto-resolved from location by default)

Output Schema

ParametersJSON Schema

Name	Required	Description
`madhab`	Yes	Active Asr jurisprudence
`timezone`	Yes	Resolved IANA timezone
`nextPrayer`	Yes	Name of the upcoming prayer
`authorityNotice`	No
`nextPrayerAtUtc`	Yes	UTC timestamp of the upcoming prayer
`selectionReason`	No
`currentLocalDate`	Yes	Current local date YYYY-MM-DD
`remainingMinutes`	Yes	Minutes remaining until prayer start
`calculationMethod`	Yes	Active calculation authority
`minuteAdjustments`	No
`nextPrayerLocalTime`	Yes	Formatted local time HH:mm
`authorityDescription`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, covering safety. The description adds meaningful behavioral context: it explicitly lists the returned data (including authority calculation method) and mandates that the LLM disclose the authority method to the user. This goes beyond the annotations and gives the agent actionable guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first clearly states the purpose, and the second delivers a critical, actionable instruction for the LLM. There is no redundancy or unnecessary detail, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with zero required parameters, a complete output schema, and annotations covering safety, the description provides all essential information: the return values and a mandatory user-facing disclosure. The schema handles parameter details, so nothing an agent needs to invoke the tool correctly is missing.

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 five parameters with their meanings and defaults. The description adds no additional parameter-level semantics, which is acceptable given the baseline of 3 for high coverage. It references 'authority calculation method' as an output, not as a parameter, so it does not enrich parameter understanding.

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 states precisely what the tool returns: the immediate next prayer name, scheduled time, authority calculation method, and countdown in minutes. This clearly differentiates it from siblings like get_today_prayer_times, which would cover today's full schedule, and get_prayer_status, which likely returns status information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by defining the output (next prayer and countdown), but it does not explicitly say when to prefer this tool over siblings, nor does it mention any exclusions or alternatives. The mandatory disclosure instruction is about post-call behavior, not tool selection. Usage context is left to inference.

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

get_prayer_preferencesRetrieve Stored Prayer PreferencesA

Read-onlyIdempotent

Inspect

Returns the currently active calculation settings and preferences for a user. Read-only operation.

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes	Unique user identifier

Output Schema

ParametersJSON Schema

Name	Required	Description
`locale`	No
`madhab`	No
`userId`	No
`enabled`	No
`message`	No
`timezone`	No
`fixedCity`	No
`locationMode`	No
`reminderMode`	No
`updatedAtUtc`	No
`fixedCoordinates`	No
`highLatitudeRule`	No
`calculationMethod`	No
`minuteAdjustments`	No
`exactWindowMinutes`	No

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the 'currently active' qualifier, which clarifies that the result reflects current settings rather than historical ones, but otherwise adds little behavioral detail beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the primary action and resource. The phrase 'Read-only operation' is slightly redundant given the annotations, but the overall structure is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read-only retrieval with full schema coverage, annotations, and an output schema, the description is complete. It tells the agent what the tool returns, that it is read-only, and the userId parameter is fully documented in 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%, and the only parameter, userId, is already described as a 'Unique user identifier' in the schema. The description does not need to add parameter meaning because the schema fully covers it.

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 uses a specific verb ('Returns') and a precise resource ('currently active calculation settings and preferences for a user'), clearly distinguishing this tool from siblings like get_today_prayer_times or get_prayer_status. The title reinforces the purpose as retrieving stored prayer preferences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates this is the tool to use when retrieving a user's current calculation settings and preferences, and the 'Read-only operation' statement clarifies it is for reading rather than configuring. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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

get_prayer_statusCheck Muslim Prayer Due StatusA

Read-onlyIdempotent

Inspect

Checks if a Muslim obligatory prayer (Fajr, Dhuhr, Asr, Maghrib, Isha) is currently due for the user location and returns active reminder details. MANDATORY: The LLM must always explicitly disclose to the user which calculation authority method was used and why it was selected (see authorityNotice in response).

ParametersJSON Schema

Name	Required	Description
`madhab`	No	Optional Asr shadow jurisprudence override (Shafi or Hanafi)
`latitude`	No	Optional explicit latitude override
`timezone`	No	Optional IANA timezone override (e.g. Asia/Riyadh)
`longitude`	No	Optional explicit longitude override
`calculationMethod`	No	Optional calculation authority override (auto-resolved from location by default)

Output Schema

ParametersJSON Schema

Name	Required	Description
`madhab`	Yes	Active Asr jurisprudence
`prayer`	No	The name of the currently due prayer if applicable
`timezone`	Yes	Resolved IANA timezone
`localDate`	Yes	Current local date in YYYY-MM-DD
`nextPrayer`	Yes	The name of the next upcoming prayer
`reminderDue`	Yes	Whether a prayer is currently due for reminder
`expiresAtUtc`	No	UTC expiration time of the active prayer window
`reminderText`	No	Localized reminder message
`startedAtUtc`	No	UTC start time of the active prayer window
`authorityNotice`	No	Mandatory theological transparency notice
`nextPrayerAtUtc`	Yes	UTC timestamp of the next upcoming prayer
`selectionReason`	No	Reason for authority selection
`calculationMethod`	Yes	Active calculation authority
`minuteAdjustments`	No	Applied minute adjustments
`authorityDescription`	No	Description of the calculation authority

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower and the description adds real value beyond them: it discloses the mandatory authority-method disclosure requirement, the location-based resolution behavior, and that it returns 'active reminder details.' It also points the agent to the authorityNotice field in the response. No contradiction with annotations.

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 with zero filler: the first front-loads the core purpose with enumeration of the specific prayers, and the second delivers the critical mandatory disclosure instruction with MANDATORY capitalization for salience. Every sentence earns its place.

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?

Given the rich supporting context (output schema for return structure, annotations for safety, 100% parameter coverage), the description is largely complete: it conveys scope, location sensitivity, and the non-negotiable disclosure behavior. The only notable gap is explicit routing guidance relative to get_next_prayer, but the 'currently due' language adequately conveys the purpose.

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 5 parameters are already documented in the schema. The description adds minimal parameter-level meaning beyond noting location-based behavior and default authority auto-resolution, both of which are also reflected in the schema. Baseline 3 is appropriate since the schema carries the burden.

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 states a specific action ('Checks if ... is currently due'), a specific resource (Muslim obligatory prayers enumerated as Fajr, Dhuhr, Asr, Maghrib, Isha), and the location-based scope. The 'currently due' phrasing semantically distinguishes it from siblings like get_next_prayer, but it never names those alternatives, so differentiation is implicit rather than explicit.

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 context is implied by 'currently due for the user location' — an agent can infer this is for checking immediate prayer obligation status rather than listing all times (get_today_prayer_times) or reading preferences (get_prayer_preferences). However, no explicit when-to-use vs when-not-to-use guidance or named alternatives are provided, leaving routing decisions to inference.

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

get_today_prayer_timesGet Full Daily Prayer TimetableA

Read-onlyIdempotent

Inspect

Retrieves today prayer timetable (Fajr, Sunrise, Dhuhr, Asr, Maghrib, Isha) in UTC and formatted local time. MANDATORY: The LLM must always explicitly disclose to the user which calculation authority method was used and why it was selected (see authorityNotice in response).

ParametersJSON Schema

Name	Required	Description
`date`	No	Date in YYYY-MM-DD format (defaults to today)
`madhab`	No	Optional Asr shadow jurisprudence override (Shafi or Hanafi)
`latitude`	No	Optional explicit latitude override
`timezone`	No	Optional IANA timezone override
`longitude`	No	Optional explicit longitude override
`calculationMethod`	No	Optional calculation authority override (auto-resolved from location by default)

Output Schema

ParametersJSON Schema

Name	Required	Description
`madhab`	Yes	Active Asr jurisprudence
`timesUtc`	Yes
`timezone`	Yes	Resolved IANA timezone
`localDate`	Yes	Local schedule date YYYY-MM-DD
`timesLocal`	Yes
`authorityNotice`	No
`selectionReason`	No
`calculationMethod`	Yes	Active calculation authority
`minuteAdjustments`	No
`authorityDescription`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and idempotent, so the description's main behavioral additions are the UTC and local-time output plus the mandatory calculation-method disclosure. This is meaningful because it tells the agent that a required user-facing disclosure exists and that the response will include authorityNotice.

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 with no filler: the retrieval purpose is front-loaded, and the mandatory disclosure is clearly flagged. Every sentence earns its place.

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 a full output schema, 100% parameter documentation, and annotations covering the safety profile, the description is nearly complete. The only notable gap is the lack of explicit guidance on when to choose this over sibling tools, but that is a usage-routing gap rather than a blocking omission.

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% and each parameter already has a clear description, so the tool description does not need to compensate. It adds minor context around calculationMethod through the mandatory disclosure requirement, but it does not provide new parameter-level semantics beyond the schema.

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 states a clear verb ('Retrieves') and a specific resource ('today prayer timetable'), and it enumerates the exact prayer times returned. The word 'today' is slightly narrower than the date parameter, which supports other dates, and it does not explicitly differentiate from siblings, so it stops short of 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for getting the full daily timetable, which contrasts implicitly with siblings like get_next_prayer and get_prayer_status. However, it never explicitly says when to use this tool versus an alternative or provides exclusions, leaving the routing decision largely to inference.

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.

3 tool updatesSep 18, 2026

Changedget_next_prayer3 fields changed

removedInput schema / properties / userId

Removed value: -{
-  "description": "Unique user or device ID",
-  "type": "string"
-}

removedOutput schema / properties / locationSource

Removed value: -{
-  "description": "Source of location resolution",
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "currentLocalDate",
-  "timezone",
-  "nextPrayer",
-  "nextPrayerAtUtc",
-  "nextPrayerLocalTime",
-  "remainingMinutes",
-  "calculationMethod",
-  "madhab",
-  "locationSource"
-]New value: +[
+  "currentLocalDate",
+  "timezone",
+  "nextPrayer",
+  "nextPrayerAtUtc",
+  "nextPrayerLocalTime",
+  "remainingMinutes",
+  "calculationMethod",
+  "madhab"
+]

Changedget_prayer_status4 fields changed

removedInput schema / properties / userId

Removed value: -{
-  "description": "Unique user or device ID for preference and deduplication tracking",
-  "type": "string"
-}

removedOutput schema / properties / dedupeKey

Removed value: -{
-  "description": "Deduplication cache key",
-  "type": "string"
-}

removedOutput schema / properties / locationSource

Removed value: -{
-  "description": "Source of location resolution",
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "reminderDue",
-  "localDate",
-  "nextPrayer",
-  "nextPrayerAtUtc",
-  "timezone",
-  "calculationMethod",
-  "madhab",
-  "locationSource"
-]New value: +[
+  "reminderDue",
+  "localDate",
+  "nextPrayer",
+  "nextPrayerAtUtc",
+  "timezone",
+  "calculationMethod",
+  "madhab"
+]

Changedget_today_prayer_times3 fields changed

removedInput schema / properties / userId

Removed value: -{
-  "description": "Unique user or device ID",
-  "type": "string"
-}

removedOutput schema / properties / coordinates

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "latitude": {
-      "description": "Latitude in degrees",
-      "type": "number"
-    },
-    "longitude": {
-      "description": "Longitude in degrees",
-      "type": "number"
-    }
-  },
-  "required": [
-    "latitude",
-    "longitude"
-  ],
-  "type": "object"
-}

changedOutput schema / required

Previous value: -[
-  "localDate",
-  "timezone",
-  "coordinates",
-  "calculationMethod",
-  "madhab",
-  "timesUtc",
-  "timesLocal"
-]New value: +[
+  "localDate",
+  "timezone",
+  "calculationMethod",
+  "madhab",
+  "timesUtc",
+  "timesLocal"
+]

5 tool updatesSep 6, 2026
- Changedconfigure_prayer_preferences3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / fixedCoordinates / additionalProperties
```
Removed value: -false
```
  - removedInput schema / properties / minuteAdjustments / additionalProperties
```
Removed value: -false
```
- Changedget_next_prayer3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedOutput schema / properties / remainingMinutes / maximum
```
Added value: +9007199254740991
```
  - addedOutput schema / properties / remainingMinutes / minimum
```
Added value: +-9007199254740991
```
- Changedget_prayer_preferences1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedget_prayer_status1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedget_today_prayer_times1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
5 tool updatesSep 6, 2026
- First observedconfigure_prayer_preferences
- First observedget_next_prayer
- First observedget_prayer_preferences
- First observedget_prayer_status
- First observedget_today_prayer_times

Related MCP Connectors

Prayer Times A
io.github.pipeworx-io
Islamic prayer times & calendar MCP (Aladhan API). Keyless.
Location Services
402
AskSakina Islamic Knowledge A
com.asksakina
Curated Islamic MCP: Quran (Arabic + Pickthall), 445 du'as, 99 Names, crisis-aware.
Knowledge & Memory
41
Wasilah A
io.github.mumullickm
Prayer times, Qibla, Hijri calendar, 99 Names, Quran audio, Bangladesh offsets. English + Bengali.
Location Services Open Data
92
prayer-times A
com.quranmajeed.time
Islamic prayer times for any city, today or the whole month, from official timetables or calculated.
Location Services Calendar Management
21

Related MCP Servers

Azan-MCP
Education & Learning Tools
ahmedeltaher
A
license
B
quality
D
maintenance
Azan-MCP is an open-source Model Context Protocol (MCP) server that brings a comprehensive suite of Islamic utilities directly into AI assistants such as Claude Desktop.
Updated 4 months ago (2026-06-02 09:38 UTC)
34
383
MIT
esolat-mcp
Location Services Art & Culture
zubir2k
A
license
A
quality
B
maintenance
MCP server providing Malaysian/global prayer times (JAKIM + Aladhan fallback), nearest mosque/surau finder, and Islamic calendar events.
Updated 17 days ago (2026-09-10 02:20 UTC)
4
1
MIT
Wasilah MCP
Location Services Search Open Data
mumullickm
A
license
Not graded
quality
B
maintenance
Remote MCP server exposing Wasilah's Islamic reference data, enabling prayer-time, Qibla, Hijri-date, and Quran-audio queries via natural language.
Updated 2 months ago (2026-07-31 08:06 UTC)
MIT
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 a month ago (2026-08-12 13:40 UTC)
34
MIT

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

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources