Muslim Prayer Reminder MCP

Configure User Prayer Preferences

configure_prayer_preferences

DestructiveIdempotent

Update persistent prayer reminder preferences—calculation method, location mode, fixed city/coordinates, timezone, prayer adjustments, and reminder display—while preserving omitted settings.

Instructions

Updates persistent prayer preferences, overwriting supplied settings while preserving omitted settings. Setting fixedCity replaces stored fixedCoordinates and stores the canonical city timezone; contradictory timezones are rejected; setting fixedCoordinates replaces stored fixedCity. Can disable reminders. Fixed mode requires a supported fixedCity or fixedCoordinates with timezone; new coordinates require timezone in the same request. clearFixedLocation removes saved location and timezone and defaults to auto_travel. Combined fixed-location calculation settings are validated for the current and next local day before saving. Invalid combinations preserve the previous preferences. Auto-travel chronology is checked when a query supplies its location. Previous values are not retained for undo.

Input Schema

Name	Required	Description
`locale`	No	Language for reminder text: en or ar
`madhab`	No	Jurisprudential Asr shadow calculation: Shafi or Hanafi
`userId`	Yes	Nonblank user identifier; at most 256 UTF-8 bytes and 256 characters. Whitespace in nonblank identifiers is preserved.
`enabled`	No	Whether prayer reminders are enabled
`timezone`	No	IANA timezone identifier (e.g. Asia/Riyadh, Europe/London)
`fixedCity`	No	Supported cities: makkah, madinah, riyadh, cairo, gaza, jerusalem, alquds, ramallah, hebron, nablus, rafah, khanyunis, dubai, abudhabi, kuwait, doha, amman, istanbul, london, paris, newyork, toronto, jakarta, singapore, karachi, kualalumpur, tehran, sydney, tromso. Aliases: gazacity, nyc, kuwaitcity. Case, spaces and punctuation are ignored.
`locationMode`	No	Location strategy: fixed uses saved location; auto_travel requires the caller to supply current city or coordinates/timezone on each query and never uses IP geolocation.
`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). For fixed locations, combined settings must preserve timetable chronology for the current and next local day before saving; auto-travel offsets are validated when a query supplies its location.
`clearFixedLocation`	No	Remove stored fixedCity, fixedCoordinates and timezone. Switches to auto_travel unless locationMode is supplied. Cannot combine with a new fixed location/timezone.
`exactWindowMinutes`	No	Duration in minutes for exact_window mode. Omitted updates preserve the saved value; if unset, the service default is 20 minutes unless the operator overrides it.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv1.1.3Oct 22, 2026

addedInput schema / properties / clearFixedLocation

Added value: +{
+  "description": "Remove stored fixedCity, fixedCoordinates and timezone. Switches to auto_travel unless locationMode is supplied. Cannot combine with a new fixed location/timezone.",
+  "type": "boolean"
+}

changedInput schema / properties / exactWindowMinutes / description

Previous value: -"Duration in minutes for exact_window mode"New value: +"Duration in minutes for exact_window mode. Omitted updates preserve the saved value; if unset, the service default is 20 minutes unless the operator overrides it."

changedInput schema / properties / fixedCity / description

Previous value: -"Predefined city name for fixed location (e.g. Riyadh, London)"New value: +"Supported cities: makkah, madinah, riyadh, cairo, gaza, jerusalem, alquds, ramallah, hebron, nablus, rafah, khanyunis, dubai, abudhabi, kuwait, doha, amman, istanbul, london, paris, newyork, toronto, jakarta, singapore, karachi, kualalumpur, tehran, sydney, tromso. Aliases: gazacity, nyc, kuwaitcity. Case, spaces and punctuation are ignored."

changedInput schema / properties / locationMode / description

Previous value: -"Location strategy: auto_travel or fixed"New value: +"Location strategy: fixed uses saved location; auto_travel requires the caller to supply current city or coordinates/timezone on each query and never uses IP geolocation."

changedInput schema / properties / minuteAdjustments / description

Previous value: -"Custom per-prayer minute offsets (-60 to +60)"New value: +"Custom per-prayer minute offsets (-60 to +60). For fixed locations, combined settings must preserve timetable chronology for the current and next local day before saving; auto-travel offsets are validated when a query supplies its location."

changedInput schema / properties / userId / description

Previous value: -"Unique user identifier"New value: +"Nonblank user identifier; at most 256 UTF-8 bytes and 256 characters. Whitespace in nonblank identifiers is preserved."

addedInput schema / properties / userId / maxLength
```
Added value: +256
```
addedInput schema / properties / userId / pattern
```
Added value: +"\\S"
```
addedOutput schema / properties / preferences / properties / fixedCityConfigured
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / properties / preferences / properties / fixedCoordinates

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "latitude": {
-      "type": "number"
-    },
-    "longitude": {
-      "type": "number"
-    }
-  },
-  "required": [
-    "latitude",
-    "longitude"
-  ],
-  "type": "object"
-}

addedOutput schema / properties / preferences / properties / fixedCoordinatesConfigured
```
Added value: +{
+  "type": "boolean"
+}
```
removedOutput schema / properties / preferences / properties / userId
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / preferences / required

Added value: +[
+  "fixedCoordinatesConfigured",
+  "fixedCityConfigured"
+]

First observedv1.0.1Sep 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: states that supplied settings overwrite while omitted ones persist, that fixedCity/fixedCoordinates mutually replace each other, that contradictory timezones are rejected, that invalid combinations preserve prior preferences, and critically that 'Previous values are not retained for undo' — which operationalizes the destructiveHint. This is exactly the kind of mutation/validation/irreversibility context structured fields cannot carry.

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?

Front-loads the core update semantics before diving into mode-specific rules, and nearly every sentence encodes a distinct constraint. It is dense and slightly verbose in places where it mirrors schema wording, but there is little true padding.

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 14-parameter destructive mutation tool with nested objects and an output schema, the description covers persistence semantics, mutual exclusivity, validation timing, and irreversibility — everything an agent needs to call it safely. Return values are properly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter precedence rules the schema describes only per-field (fixedCity replaces stored fixedCoordinates, fixedCoordinates replaces fixedCity, clearFixedLocation and combined setting validation). It adds meaning beyond the per-parameter descriptions, though some sentences restate schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Updates persistent prayer preferences') and immediately characterizes the update semantics as merge-style ('overwriting supplied settings while preserving omitted settings'). This clearly separates it from the read-only siblings get_prayer_preferences / get_prayer_status without needing to name them.

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?

Gives concrete conditions for the key modes: fixed mode requires a supported city or coordinates+timezone, new coordinates require a timezone in the same request, clearFixedLocation defaults to auto_travel, and contradictory timezones are rejected. It does not explicitly say when to prefer this tool over get_prayer_preferences or when NOT to call it, so it falls short of a 5.

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

Deploy Server