This MCP server provides Islamic worship tools for Malaysia and globally, with prayer times, nearby mosques, and Islamic calendar events.
Get prayer times: Fetch monthly prayer schedules (Fajr, Syuruk, Dhuha, Dhuhr, Asr, Maghrib, Isha) by location name or GPS coordinates, including Gregorian and Hijri dates (with Malay month names).
Find nearest mosques/suraus: Search up to 15 nearby places within a configurable radius (default 5 km), with distance, coordinates, and Google Maps/Waze deep links; uses official e-Solat data for Malaysia and OpenStreetMap globally.
Get yearly Islamic events: Retrieve major Islamic dates (e.g., Eid) for a given year, Malaysia-aware.
Get current server time: Useful for real-time comparisons like time remaining to next prayer (though Hijri dates come via the other tools).
Dual deployment: Run locally via stdio or remotely via Docker + HTTP with a health dashboard.
Data sources: Official JAKIM/e-Solat API for Malaysia, Aladhan for global fallback, and Overpass for mosque data.
Generates direct links to Google Maps for nearby mosques/suraus.
Uses OpenStreetMap data to find and locate nearby mosques and suraus.
Generates direct links to Waze for nearby mosques/suraus.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@esolat-mcp prayer times for Kuala Lumpur today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for accurate Malaysian prayer times (official JAKIM/e-Solat), nearest masjid and surau, and Islamic calendar events.
Gives AI assistants like Claude Desktop and Claude Code reliable, hallucination-free access to Islamic worship tools with smart Malaysia-first routing.
Official JAKIM data for Malaysia (via Waktusolat.app API)
Dhuha time automatically calculated (+28 minutes after Syuruk)
Malay Hijri month names (Muharram, Safar, etc.)
Global fallback using Aladhan API
Nearest mosques/suraus with Google Maps + Waze deep links
Yearly Islamic events (Eid, etc.)
Dual mode: Local (stdio) + Remote (Docker + secure HTTP)
Health dashboard for upstream APIs
Related MCP server: Azan-MCP
The server registers three powerful tools that Claude can discover and call automatically:
get_monthly_prayer_times
Get full monthly prayer schedule (Fajr, Syuruk, Dhuha, Dhuhr, Asr, Maghrib, Isha)
Accepts place name or latitude/longitude
Returns both Gregorian and Hijri dates
find_nearest_mosques
Find up to 15 nearest masjid/surau
Default radius: 5 km (configurable)
Malaysia uses official e-Solat data; global uses OpenStreetMap
Includes distance, coordinates, Google Maps & Waze links
get_yearly_islamic_events
Major Islamic dates and holidays for a given year
Malaysia-aware routing
No clone needed:
uvx esolat-mcpClaude Desktop config example:
{
"mcpServers": {
"esolat": {
"command": "uvx",
"args": ["esolat-mcp"]
}
}
}1. Clone the repo and set up token:
git clone https://github.com/zubir2k/esolat-mcp.git
cd esolat-mcp
cp .env.example .env2. Generate a strong token:
python -c "import secrets; print(secrets.token_urlsafe(32))"
# or: openssl rand -hex 323. Paste it into .env as MCP_WEBHOOK_TOKEN=your_token_here
4. Build and Start the container:
docker build -t esolat-mcp:latest .
docker compose up -d5. Endpoints
- Streamable MCP HTTP Endpoint (main one for AI clients):
http://your-server-ip:8626/api/webhook/<MCP_WEBHOOK_TOKEN>/mcp- Health Dashboard (useful for monitoring):
http://your-server-ip:8626/api/webhook/<MCP_WEBHOOK_TOKEN>(GET request without /mcp — shows status of JAKIM, Aladhan, and Overpass APIs)
Always keep yourMCP_WEBHOOK_TOKEN secret.
The token is part of the URL path for simple authentication. You can change the local port via the PORT environment variable.
For production: Consider using a reverse proxy (Nginx/Cloudflare) with HTTPS to prevent the token from being intercepted or leaked in access logs.
Prefer a simpler setup? If you want a no-server, no-Docker solution that runs on the edge, consider my Cloudflare Worker edition (free tier eligible). It automatically enforces HTTPS and avoids the self-hosting risks mentioned above.
👉 Head over to the repo: zubir2k/esolat-cfworker
"What are today's prayer times in Kuala Lumpur?"
"Show me full prayer schedule for Penang this Ramadan."
"Prayer times for Kota Kinabalu next week."
"Find the nearest mosque to me."
"Mosques within 10km of Petaling Jaya."
"Nearest surau from KLCC."
"Major Islamic events in 2026 for Malaysia."
"Plan my trip to Johor Bahru: prayer times + nearest mosques + Eid dates."
e-solat JAKIM - For the official prayer times
WaktuSolat.app - Prayer Time by GPS
Model Context Protocol - For the MCP framework
This project is licensed under the MIT License.
This integration pulls data directly from the official e-Solat JAKIM (Department of Islamic Development Malaysia) portal. However, please note:
No Liability: This integration is a community-driven project provided "as is" without any guarantees. The maintainer is not solely or legally responsible for any discrepancies, inaccuracies, delays, or omissions in prayer times or calendar dates.
Verify Important Times: Users are strictly advised to regularly check and verify times against the official JAKIM eSolat Portal or official local announcements, especially for critical obligations (e.g., fasting, community prayers).
Network & Upstream Dependencies: Synchronization depends on upstream API availability and local network connectivity. Discrepancies caused by unexpected server updates from JAKIM or local server downtime are outside the control of this software.
By using this tool, you acknowledge and agree that the developer holds no liability for missed schedules or data inaccuracies.
Finds verified mosques, masjids, or suraus within a target search radius. Injects map routing navigation strings for Google Maps and native Waze applications.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | ||
| longitude | No | ||
| distance_km | No | ||
| location_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the behavioral trait of injecting map routing strings. However, it does not disclose permissions, rate limits, or whether it is read-only, leaving gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and key feature. No extraneous text, though it could benefit from a structured parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks detail on return format beyond routing strings. With no parameter descriptions and no annotations, important context like how to specify location is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only indirectly references the distance_km parameter via 'target search radius'. No explanation of location_name, latitude, longitude, or default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds verified mosques/masjids/suraus within a radius and injects map routing strings. It is distinct from sibling tools (prayer times and events) with a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied (find mosques near a location) but no explicit when-to-use, when-not-to-use, or alternatives are given. The sibling tools are different, but no guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current server UTC time. Use this tool first when the user asks about current prayer status, time remaining to next prayer, or any query that requires comparing current time against prayer times. For the Hijri date, use get_monthly_prayer_times or get_yearly_islamic_events instead, since the Hijri calendar is region-dependent (moonsighting-based) and those tools return the authoritative date sourced from JAKIM/Aladhan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function. It does not disclose any behavioral traits such as rate limits, authentication requirements, or whether the tool is read-only. For a simple time-fetch, this is adequate but minimal, hence a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose. Every sentence earns its place: first defines what it does, second gives usage context, third distinguishes from siblings. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or content. It would be more complete if it mentioned the time format (e.g., ISO 8601) or any additional details. However, the context signals indicate a simple tool with no parameters, and the description provides adequate context for when to use it relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description adds no parameter information because there are none. For zero-parameter tools, the baseline is 4. The description does not need to add anything beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Returns the current server UTC time'. The verb 'returns' and resource 'current server UTC time' are specific. Distinguishes from sibling tools by specifying that for Hijri date, other tools should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user asks about current prayer status, time remaining to next prayer, or any query that requires comparing current time against prayer times'. Also specifies when not to use and provides alternative tools (get_monthly_prayer_times, get_yearly_islamic_events) for Hijri dates. This provides clear guidance and differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches comprehensive monthly prayer times based on raw GPS coordinates or location name string text. Computes precise Dhuha intervals (+28 mins from Syuruk) and normalizes Hijri month texts. Use this tool whenever the user asks for today's prayer times, this week's schedule, or a specific month's prayer schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| month | No | ||
| latitude | No | ||
| longitude | No | ||
| location_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must reveal behavioral traits. It mentions computing Dhuha intervals and normalizing Hijri months, but does not disclose rate limits, data freshness, or whether it is read-only. No contradictions with annotations since none provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a usage instruction. It front-loads the main action and every sentence adds value. Minor improvement could be better structuring parameter relationships.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description covers purpose and usage scenarios adequately but lacks detail on parameter semantics and edge cases (e.g., conflicting inputs). Overall sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions GPS coordinates or location name, partially covering location_name, latitude, longitude, but does not explain month and year parameters or their optionality/format. Parameter semantics are inadequately conveyed beyond a high level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches comprehensive monthly prayer times based on GPS coordinates or location name. It specifies computing Dhuha intervals and normalizing Hijri months, distinguishing it from siblings like find_nearest_mosques and get_yearly_islamic_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool whenever the user asks for today's prayer times, this week's schedule, or a specific month's schedule. This provides clear context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves significant Islamic calendar milestones for a target year. Defaults to the current year if not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | ||
| longitude | No | ||
| target_year | No | ||
| location_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the default-year behavior but fails to mention that location parameters (location_name, latitude, longitude) could affect the events returned. No disclosure on permissions or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Every word serves a purpose. The default-behavior detail is well placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 required parameters and existing output schema, the description is minimally adequate. But it omits explanation of location parameters and the nature of 'milestones,' which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only adds default value info for target_year. It does not explain the purpose or effect of location_name, latitude, or longitude, leaving their meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'significant Islamic calendar milestones for a target year' and mentions defaulting to current year. This specific verb+resource structure distinguishes it from sibling tools like find_nearest_mosques and get_monthly_prayer_times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes defaulting to current year, providing some usage context, but does not explicitly state when to use this tool over alternatives or when not to use it. Since siblings are clearly different, the implication is sufficient but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3get_current_timev1.0.1find_nearest_mosques1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ ],
+ "title": "Result"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "find_nearest_mosquesOutput",
+ "type": "object"
+}get_monthly_prayer_times1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ ],
+ "title": "Result"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_monthly_prayer_timesOutput",
+ "type": "object"
+}get_yearly_islamic_events2 fields changedInput schema / properties / target_year / defaultPrevious value: -2026New value: +nullOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ ],
+ "title": "Result"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_yearly_islamic_eventsOutput",
+ "type": "object"
+}v1.0.0find_nearest_mosquesget_monthly_prayer_timesget_yearly_islamic_eventsScored across 4 tools
Each tool has a clearly distinct purpose: find mosques, get current time, get monthly prayer times, and get yearly Islamic events. No overlap in functionality.
All tools use snake_case and a verb_noun pattern, but 'find_nearest_mosques' uses 'find' while the others use 'get', which is a minor deviation from full consistency.
With 4 tools, the set is appropriately scoped for the domain of Islamic prayer information. Each tool serves a necessary and distinct role without redundancy.
The tool surface covers the core needs: locating mosques, current time, monthly prayer schedules, and yearly Islamic events. There are no obvious gaps for typical user queries.
Islamic prayer times & calendar MCP (Aladhan API). Keyless.
Quran MCP server for translation, tafsir, mutashabihat, recitation playlists, and prayer times.
Production-ready Muslim prayer reminder MCP with astronomical precision and theological disclosure.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
