This server calculates Jewish prayer times (zmanim) for any location worldwide using accurate NOAA-based astronomical calculations, supporting multiple halachic opinions and flexible output formats.
Core Capabilities:
Sunrise & Sunset Times — Calculate precise sunrise and sunset for any geographic location and date.
Latest Shema Times — Retrieve the morning Shema deadline per GR"A (3 temporal hours after sunrise) and MG"A (3 temporal hours from dawn).
Latest Morning Prayer Times — Calculate the Shacharis cutoff per GR"A (4 hours after sunrise) and MG"A (4 temporal hours from dawn).
Mincha Prayer Times — Get Mincha Gedola (earliest, 30 min after midday), Mincha Ketana (2.5 hours before sunset), and Plag HaMincha (1.25 hours before sunset).
Shabbat Times — Calculate candle lighting (customizable offset, default 18 min before sunset), sunset, and Havdalah (72 minutes after sunset).
All Daily Zmanim — A comprehensive daily schedule including Alos HaShachar (dawn), sunrise, Shema, Tefila, Chatzos (solar noon), all Mincha times, sunset, and nightfall.
Additional Features:
Accepts any global location via latitude/longitude and IANA timezone
Optional date input (defaults to today)
Output in Markdown (human-readable) or JSON (machine-readable) format
Gracefully handles edge cases like polar locations (returns "N/A")
Click on "Deploy 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., "@Zmanim MCP Server Get Shabbat candle lighting times for Jerusalem this Friday."
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.
A comprehensive MCP server for calculating Jewish prayer times (zmanim).
A comprehensive Model Context Protocol (MCP) server for calculating Jewish prayer times (zmanim) using the python-zmanim library.
This MCP server provides tools to calculate various Jewish prayer times and astronomical times for any location worldwide. It uses the python-zmanim library, which is a Python port of the KosherJava project, implementing accurate astronomical calculations based on the NOAA algorithm.
Related MCP server: MCP Node Time
zmanim_get_sunrise_sunset - Get sunrise and sunset times
zmanim_get_shema_times - Get latest times for reciting the morning Shema (GR"A and MG"A opinions)
zmanim_get_tefila_times - Get latest times for morning prayer/Shacharis (GR"A and MG"A opinions)
zmanim_get_mincha_times - Get times for afternoon prayer including Mincha Gedola, Mincha Ketana, and Plag HaMincha
zmanim_get_shabbat_times - Get Shabbat candle lighting and Havdalah times
zmanim_get_daily_times - Get a comprehensive set of all daily zmanim
✅ Support for multiple halachic opinions (GR"A, MG"A)
✅ Accurate NOAA-based astronomical calculations
✅ Support for any global location with latitude/longitude
✅ Timezone-aware calculations
✅ Optional date specification (defaults to today)
✅ Multiple output formats (Markdown and JSON)
✅ Customizable candle lighting offset
✅ Comprehensive error handling
# For use with Claude Desktop or other MCP clients
uvx zmanim-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"zmanim": {
"command": "uvx",
"args": ["zmanim-mcp-server"]
}
}
}Get sunrise and sunset times for New York City today:
- Location: New York, NY
- Latitude: 40.7128
- Longitude: -74.0060
- Time Zone: America/New_YorkWhat time is the latest I can say Shema in Jerusalem?
- Location: Jerusalem
- Latitude: 31.7683
- Longitude: 35.2137
- Time Zone: Asia/JerusalemGet Shabbat candle lighting and Havdalah times for Chicago this Friday:
- Location: Chicago, IL
- Latitude: 41.8781
- Longitude: -87.6298
- Time Zone: America/Chicago
- Candle lighting offset: 18 minutes (can be customized)Give me all the prayer times for London today:
- Location: London
- Latitude: 51.5074
- Longitude: -0.1278
- Time Zone: Europe/LondonAlos HaShachar (Dawn): First light, 72 minutes before sunrise
Sunrise (Hanetz HaChama): When the sun rises above the horizon
Sof Zman Krias Shema: Latest time to recite the morning Shema
GR"A: 3 hours after sunrise
MG"A: 3 temporal hours from dawn (typically earlier)
Sof Zman Tefila: Latest time for morning prayer (Shacharis)
GR"A: 4 hours after sunrise
MG"A: 4 temporal hours from dawn (typically earlier)
Chatzos: Solar noon, midpoint between sunrise and sunset
Mincha Gedola: Earliest time for afternoon prayer (30 minutes after midday)
Mincha Ketana: Preferred earliest time for Mincha (2.5 hours before sunset)
Plag HaMincha: 1.25 hours before sunset (latest time according to some opinions)
Sunset (Shkiah): When the sun sets below the horizon
Tzeis HaKochavim: Nightfall, when stars appear (72 minutes after sunset)
Candle Lighting: Typically 18-40 minutes before sunset (varies by community)
Havdalah: When Shabbat ends, typically at Tzeis (72 minutes after sunset)
The server supports calculations according to different halachic authorities:
GR"A (Vilna Gaon): Calculates day from sunrise to sunset
MG"A (Magen Avraham): Calculates day from dawn (72 minutes before sunrise) to nightfall
Human-readable format with clear headers and organized sections, perfect for display.
Machine-readable structured data including ISO 8601 timestamps, suitable for programmatic use.
All tools accept the following parameters:
location (required): Name of the location (e.g., "New York, NY")
latitude (required): Latitude in decimal degrees (-90 to 90)
longitude (required): Longitude in decimal degrees (-180 to 180)
time_zone (required): IANA timezone identifier (e.g., "America/New_York")
date (optional): Date in YYYY-MM-DD format (defaults to today)
response_format (optional): "markdown" or "json" (defaults to markdown)
For Shabbat times, there's an additional parameter:
candle_lighting_offset (optional): Minutes before sunset (1-60, default 18)
Uses the NOAA (National Oceanic and Atmospheric Administration) algorithm
Accounts for atmospheric refraction
Timezone-aware using IANA timezone database
Elevation can be incorporated in calculations
fastmcp: Standalone FastMCP framework
zmanim: Python port of KosherJava zmanim library
pydantic: Input validation and data modeling
Location | Latitude | Longitude | Timezone |
Jerusalem | 31.7683 | 35.2137 | Asia/Jerusalem |
New York | 40.7128 | -74.0060 | America/New_York |
Los Angeles | 34.0522 | -118.2437 | America/Los_Angeles |
London | 51.5074 | -0.1278 | Europe/London |
Paris | 48.8566 | 2.3522 | Europe/Paris |
Sydney | -33.8688 | 151.2093 | Australia/Sydney |
Toronto | 43.6532 | -79.3832 | America/Toronto |
Miami | 25.7617 | -80.1918 | America/New_York |
Check that the path in your configuration is correct
Ensure Python and all dependencies are installed
Verify the configuration file syntax is valid JSON
Restart your MCP client after configuration changes
This typically occurs for locations near the poles where the sun doesn't rise or set on certain days. The calculations handle this gracefully by returning "N/A".
Ensure you're using valid IANA timezone identifiers. You can find a list at: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
This MCP server uses the python-zmanim library, which is licensed under the GNU Lesser General Public License v2 or later (LGPLv2+), ported from the KosherJava project.
Based on the python-zmanim library by pinnymz
Original Java library: KosherJava by Eliyahu Hershfeld
NOAA astronomical calculations
For issues related to:
This MCP server: Please open an issue with details about your configuration and the problem
Zmanim calculations: Refer to the python-zmanim repository
Halachic questions: Consult your local rabbi or posek
Potential additions to consider:
Hebrew date calculations
Fast day times
Molad calculations
Holiday determination
Custom opinion configurations
Multi-day range queries
Export to calendar formats (iCal)
Note: This server is for informational purposes. For practical halachic decisions, please consult a qualified rabbi.
Get a comprehensive set of daily zmanim (Jewish prayer times) for a location.
This tool provides all major zmanim for the day including:
Alos HaShachar (dawn)
Sunrise
Latest times for Shema (GR"A and MG"A)
Latest times for Tefila (GR"A and MG"A)
Chatzos (midday)
Mincha times
Sunset
Tzeis HaKochavim (nightfall)
Args: params (LocationInput): Input parameters containing location and date information
Returns: str: Complete set of daily zmanim in the requested format
Example: Use this tool to get a complete daily schedule of prayer times for any location.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that the tool returns a string in requested format (markdown or json) and lists the included times. This provides some behavioral context beyond annotations but is not extensive. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at about 10 lines, including a bullet list of returned times. It front-loads the core purpose and then lists specifics. Some redundancy exists in the full description, but overall it is well-structured and not verbose. Slight improvement could be achieved by merging the return format mention more concisely.
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 tool's moderate complexity (multiple input parameters, output format options, listing many times), the description covers the output comprehensively and mentions format. Annotations cover idempotence and read-only. The schema fully documents parameters. No output schema is visible but context says it exists. The description is sufficient for an agent to understand and use the tool effectively.
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 indicated as 0%, but the input schema actually contains detailed descriptions for each property (location, latitude, longitude, time_zone, date, response_format). The tool description only vaguely mentions 'params (LocationInput): Input parameters containing location and date information' without adding new semantics. Since schema already covers parameters, baseline of 3 is appropriate.
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?
Description clearly states it provides a comprehensive set of daily zmanim, listing major times. Annotations title 'Get All Daily Zmanim' matches. The tool name 'zmanim_get_daily_times' and the list of included times distinguish it from sibling tools like zmanim_get_mincha_times, which focus on subsets. Purpose is specific and unambiguous.
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?
Description explicitly states 'Use this tool to get a complete daily schedule of prayer times for any location.' While it does not list when to avoid, the contrast with sibling tools (which are more specific) implies that this tool is for full schedules and others for partial. This provides clear context for selection, though explicit exclusion of alternatives would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the times for Mincha (afternoon prayer) including Mincha Gedola and Mincha Ketana.
This tool calculates when the afternoon prayer can be recited:
Mincha Gedola: Earliest time (30 minutes after midday/chatzos)
Mincha Ketana: Preferred earliest time (2.5 hours before sunset)
Plag HaMincha: Latest time according to some opinions (1.25 hours before sunset)
Args: params (LocationInput): Input parameters containing location and date information
Returns: str: All relevant Mincha times in the requested format
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description explains the meaning of Mincha Gedola, Mincha Ketana, and Plag HaMincha, providing useful context about what the tool calculates. It does not cover rate limits or auth, but annotations already declare safety.
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, front-loads the main purpose, and includes a helpful bullet list of times. No extraneous information, though it could be slightly more streamlined.
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 annotations and well-described schema, the description adequately explains the tool's output (three Mincha times) and their definitions. It is complete for a specific prayer-time tool, though it does not mention the reliance on Jewish calendar calculations (inherent).
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 input schema already has detailed descriptions for each property (location, latitude, etc.), so schema coverage is high. The tool description only restates that params contain location and date, adding no extra meaning beyond the schema.
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 'Get the times for Mincha' with specific verb and resource, and lists the three distinct times (Mincha Gedola, Mincha Ketana, Plag HaMincha). It distinguishes from sibling tools which target other prayer times or daily 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?
No explicit guidance on when to use this tool vs alternatives like zmanim_get_shema_times or zmanim_get_shabbat_times. The agent must rely on tool names to differentiate. No when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Shabbat candle lighting and Havdalah times for a specified location and date.
This tool calculates:
Candle lighting time (before sunset, typically 18-40 minutes depending on custom)
Sunset time (when Shabbat begins)
Tzeis HaKochavim (nightfall, when Shabbat ends, 72 minutes after sunset)
Args: params (CandleLightingInput): Input parameters including: - location, latitude, longitude, time_zone, date (from LocationInput) - candle_lighting_offset: Minutes before sunset (default 18)
Returns: str: Shabbat times in the requested format
Note: Different communities have different customs for candle lighting time. Jerusalem uses 40 minutes, while many communities use 18 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. The description adds behavioral context like the offset default and community customs, which is helpful beyond annotations.
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 well-structured with a clear purpose, bulleted list of calculated times, and note about customs. It is efficient with few wasted words.
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 tool's complexity and the presence of an output schema, the description covers the key aspects without being overly detailed. It mentions custom offsets and response formats.
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 description summarizes the main parameters but adds limited extra meaning beyond the schema's own descriptions. With schema coverage being rich, baseline 3 is appropriate.
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 gets Shabbat candle lighting and Havdalah times for a specified location and date, listing the specific times calculated. This distinguishes it from sibling tools for other Zmanim calculations.
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 implies usage for Shabbat time queries but lacks explicit when-to-use or alternatives. However, the tool name and context make it obvious, so it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest times for reciting the morning Shema according to different opinions.
This tool calculates the deadline for reciting the morning Shema (Krias Shema) according to two major halachic opinions: the GR"A (Vilna Gaon) and the Magen Avraham (MG"A). The GR"A calculation is 3 hours after sunrise, while the MG"A is based on 3 temporal hours from dawn (72 minutes before sunrise).
Args: params (LocationInput): Input parameters containing location and date information
Returns: str: Latest times for Shema according to both opinions in the requested format
Note: The MG"A time is typically earlier and more stringent than the GR"A time.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds context about the two halachic opinions and their differences, which goes beyond annotations but does not disclose potential edge cases or failure modes.
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 four sentences, front-loaded with the main purpose, and includes a useful note about the difference between the two opinions. Every sentence adds value without redundancy.
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 presence of an output schema, the description does not need to detail return values. It explains the two opinions and mentions output format flexibility. It could sometimes state the default format or order of outputs, but overall it is sufficiently complete for a focused list tool.
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 description only briefly mentions the params argument as 'Input parameters containing location and date information.' The input schema provides detailed descriptions for each subfield (location, latitude, etc.), so schema coverage is high. The description adds minimal value beyond what the schema already offers.
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 gets the latest times for reciting the morning Shema according to two major opinions (GR"A and MG"A), using specific verbs and resource. It distinguishes itself from sibling tools like zmanim_get_daily_times and zmanim_get_tefila_times by focusing on Shema.
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 explains the two calculations and notes that MG"A is earlier and more stringent, but does not explicitly state when to use this tool versus alternatives. It lacks 'when to use' or 'when not to use' guidance, leaving the agent to infer based on the Shema focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sunrise and sunset times for a specified location and date.
This tool calculates the times of sunrise and sunset based on astronomical calculations, taking into account the geographic location. The calculations use the NOAA algorithm for accuracy.
Args: params (LocationInput): Input parameters containing: - location (str): Name of the location - latitude (float): Latitude in decimal degrees (-90 to 90) - longitude (float): Longitude in decimal degrees (-180 to 180) - time_zone (str): IANA timezone identifier - date (Optional[str]): Date in YYYY-MM-DD format (defaults to today) - response_format (ResponseFormat): 'markdown' or 'json'
Returns: str: Formatted sunrise and sunset times in the requested format
Example: For New York on a winter day, sunrise might be at 7:15 AM and sunset at 4:30 PM.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds value by specifying the use of the NOAA algorithm, the return format options, and an example. However, it does not discuss error handling or boundary conditions.
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 opens with a clear purpose and is well-structured. However, the Args section duplicates schema descriptions, adding unnecessary length. Could be more concise.
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?
For a simple read-only tool, the description covers purpose, algorithm, parameters, return format, and an example. It is sufficient for typical use, though it lacks error handling details. Given the presence of an output schema, completeness is good.
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 input schema provides full descriptions for all parameters, including constraints and examples. The description's Args section merely replicates this information, adding no new semantic value. Baseline score of 3 is appropriate given high schema coverage.
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 returns sunrise and sunset times for a location and date, using a specific algorithm. However, it does not differentiate from sibling tools like zmanim_get_daily_times, which might also include these 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?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest times for morning prayer (Tefila/Shacharis) according to different opinions.
This tool calculates the deadline for reciting the morning Shemoneh Esrei according to two major halachic opinions: the GR"A (4 hours after sunrise) and the MG"A (4 temporal hours from dawn).
Args: params (LocationInput): Input parameters containing location and date information
Returns: str: Latest times for Tefila according to both opinions in the requested format
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds calculation context (GR"A vs MG"A) and return format, with no contradiction to annotations.
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 and well-structured: purpose first, then explanation of opinions, then args and returns. Every sentence adds value.
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 complexity of location-based calculations and two opinions, the description covers essential context. It mentions return format but could clarify default date behavior, though that is in the schema.
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 input schema itself has detailed property descriptions. The tool description provides a high-level summary of the params object, adding some value but not fully compensating for the lack of param description.
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 states it gets the latest times for morning prayer (Tefila/Shacharis) according to two opinions, clearly distinguishing it from sibling tools for daily, mincha, shabbat, shema, and sunrise/sunset 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 implies use for morning prayer deadlines and lists two halachic opinions, but does not explicitly state when to use this tool over siblings or provide exclusions.
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.
v0.2.0zmanim_get_daily_timeszmanim_get_mincha_timeszmanim_get_shabbat_timeszmanim_get_shema_timeszmanim_get_sunrise_sunsetzmanim_get_tefila_timesScored across 6 tools
Tools are mostly distinct, with each focusing on specific prayer times (Mincha, Shabbat, Shema, etc.). However, the comprehensive 'daily_times' tool subsumes many of the others, potentially causing an agent to select it instead of a more specific tool.
All tools follow a consistent 'zmanim_get_<descriptive_noun>' pattern in snake_case. This makes it easy for an agent to understand the purpose and predict tool names.
Six tools cover the major categories of Jewish daily prayer times (general, Mincha, Shabbat, Shema, sunrise/sunset, Tefila) without being excessive or sparse. The count is well-scoped for this domain.
The set covers most core daily zmanim needs. However, it lacks tools for holiday-specific times (e.g., Yom Kippur) or fast day times, which would be expected for a comprehensive zmanim server.
A simple MCP server built with FastMCP and python
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
Primarily to be used as a template repository for developing MCP servers with FastMCP in Python, P…
