A
licenseA
qualityD
maintenanceA comprehensive MCP server for calculating Jewish prayer times (zmanim) using the python-zmanim library, supporting multiple halachic opinions and global locations.
6
1
MIT
hebcal-mcp
Officialby hebcal
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., "@hebcal-mcpList Jewish holidays for 2025"
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.
Hebcal Jewish holidays and Hebrew calednar Model Context Protocol (MCP) server
Hebcal (pronounced HEEB-kal, as in Hebrew calendar) is a free Jewish calendar and holiday web site.
Our mission is to increase awareness of Jewish holidays and to help Jews to be observant of the mitzvot.
This repository is the MCP server equivalent of the powerful custom Jewish calendar tool that lets you generate a list of Jewish holidays for any year (past, present or future).
Also available are a Hebrew date converter, Shabbat candle lighting times and Torah readings (both full kriyah and triennial system), and a page to look up yahrzeits, birthdays and anniversaries.
Running the Server
This MCP server can run in two modes:
Stdio Mode (default): Communicates over standard input/output.
npm install npm run build node build/cli.jsServer-Sent Events (SSE) Mode: Communicates over HTTP using SSE.
npm install npm run build node build/server.jsThe SSE endpoint will be available at
http://localhost:8080/mcpby default. You can configure the port using theNODE_PORTenvironment variable (e.g.,NODE_PORT=3000 node build/server.js).You can test the SSE endpoint with
curl:curl -N http://localhost:8080/mcpThen, in a separate terminal, you can send MCP requests (as JSON) to the server via its stdin if you are also running it in stdio mode, or by sending HTTP POST requests if you were to implement an HTTP ingress for requests. For now, the SSE transport only handles outgoing messages. For a full duplex SSE communication, the client would also need to send requests to the server (e.g. via POST requests to a different endpoint). This example focuses on the server sending events to the client.
Available Tools
7 toolsconvert-gregorian-to-hebrewAInspect
Converts a Gregorian (civil) date to a Hebrew date (Jewish calendar)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date (in yyyy-MM-dd format) to convert |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It states the conversion but does not mention error handling, behavior on invalid dates, or any other traits beyond the basic operation.
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 a single, succinct sentence that immediately conveys the purpose with no extraneous words.
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?
Given the tool's simplicity (single parameter, basic conversion), the description is sufficiently complete. No output schema or nested objects are needed.
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 coverage is 100%, so the schema already documents the parameter. The description does not add any additional meaning beyond what the schema provides.
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 clearly states the action (converts) and the resource (Gregorian date to Hebrew date), and it distinguishes itself from the sibling tool 'convert-hebrew-to-gregorian' which does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, such as when to use Hebrew-to-Gregorian conversion or any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert-hebrew-to-gregorianBInspect
Converts a Hebrew date to a Gregorian (civil) date
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Hebrew day of month | |
| month | Yes | Hebrew month name transliterated, like Elul or Tishrei | |
| year | Yes | Hebrew year |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral traits. It fails to mention edge cases like leap years, month name validation, or error handling, providing minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but it is too minimal, lacking details that would make it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, and with a terse description, the tool definition is incomplete. It does not explain return format, potential errors, or validation rules.
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 coverage is 100% with descriptions for each parameter, so the description adds no extra meaning beyond what the schema already provides.
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 clearly states the action ('converts') and the resource ('Hebrew date to Gregorian date'), distinguishing it from the sibling 'convert-gregorian-to-hebrew' which does the reverse.
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 is implied by the name and description, but no explicit guidance is given on when to use this tool versus alternatives like 'convert-gregorian-to-hebrew' or other calendar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daf-yomiAInspect
Calculates the Daf Yomi (Babylonian Talmud) learning for a specified date
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date in yyyy-MM-dd format |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose error handling, date validation, or what the calculation returns, leaving behavioral traits ambiguous for a simple read-only tool.
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?
One sentence of 12 words, concise and front-loaded; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is adequate but lacks indication of the return value format or any limitations.
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?
The single parameter is already fully described in the schema (format yyyy-MM-dd); the description adds no extra meaning beyond 'specified date'.
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 clearly states the verb 'calculates' and the resource 'Daf Yomi learning for a specified date', distinguishing it from sibling tools about calendar conversions and holidays.
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?
No explicit guidance on when to use this tool versus alternatives, but the context is implied given the tool's specific function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jewish-holidays-yearBInspect
Calculates a list of all Jewish holidays during a Gregorian (civil) year
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Gregorian year |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral details. It does not disclose the format or scope of holidays (e.g., major/minor, including fasts), nor any edge cases like year validity.
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 a single sentence, very concise. However, it could be slightly more informative without sacrificing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input and no output schema, the description is minimally complete. It lacks mention of holiday types or formatting, leaving some ambiguity.
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?
The single parameter 'year' has a schema description 'Gregorian year', and the tool description adds 'civil' but no additional detail. Schema coverage is 100%, so baseline is 3; the description adds minimal meaning.
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 clearly states the tool calculates a list of all Jewish holidays for a Gregorian year, using a specific verb and resource. It differentiates itself from sibling tools like convert-gregorian-to-hebrew and shabbat-times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings. For example, there is no mention that this tool is for annual holiday lists while torah-portion is for weekly readings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shabbat-timesAInspect
Generates Shabbat and holiday candle-lighting and Havdalah times for a given location and date range
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude as decimal, valid range -90 to +90 (e.g. 41.85003) | |
| longitude | Yes | Longitude as decimal, valid range -180 to +180 (e.g. -87.65005) | |
| tzid | Yes | Olson timezone ID (e.g. "America/Chicago", "Europe/Moscow") | |
| startDate | Yes | Start date in yyyy-MM-dd format | |
| endDate | Yes | End date in yyyy-MM-dd format |
TDQS
A3.5/5.0
Behavior2/5
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 output type (times) without detailing behavioral aspects like output format, handling of remote locations, or error cases. This is minimal transparency.
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 a single, concise sentence that front-loads the key action ('Generates Shabbat... times') and provides necessary context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description omits what the output looks like (list of times, possibly with dates) and whether it covers all holidays. It is somewhat complete for a simple query but lacks output details.
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 coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate.
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 clearly states the tool's purpose: generating Shabbat and holiday times (candle-lighting and Havdalah) for a given location and date range. This distinguishes it from sibling tools like 'daf-yomi' or 'torah-portion'.
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 when needing Shabbat/holiday times, but does not specify when not to use it (e.g., for non-holiday dates) or suggest alternatives. It provides no explicit guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torah-portionAInspect
Calculates the weekly Torah portion (also called parashat haShavua) for a specified date
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date in yyyy-MM-dd format | |
| il | Yes | True if in Israel, false for Diaspora |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must stand alone. It describes a calculation operation but adds no details about data sources, accuracy, or side effects. Adequate for a simple read-only operation.
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, clear sentence with no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks specification of the output format (e.g., portion name, reference). Since there is no output schema, the agent is left guessing what the tool returns. Adequate for a simple tool but incomplete.
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?
Both parameters are fully described in the schema (date format and boolean for region). The description does not add extra meaning beyond what the schema already provides, meeting the baseline for high schema coverage.
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 clearly states the verb ('calculates') and the resource ('weekly Torah portion'), distinguishing it from siblings like daf-yomi, shabbat-times, or date conversion tools.
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?
No explicit when-to-use or alternative recommendations are provided. The purpose is clear enough to infer usage, but the description does not guide on when not to use or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
yahrzeitCInspect
Calculates the Yahrzeit, the anniversary of the day of death of a loved one, according to the Hebrew calendar for a specified date
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date of death (in yyyy-MM-dd format) | |
| afterSunset | Yes | after sunset |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states calculation without disclosing non-obvious behaviors: return format, error handling, side effects, or idempotency. Agent cannot anticipate output structure.
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?
Single sentence, front-loaded with core action. No unnecessary words. Efficient and clear for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description omits return value (e.g., Hebrew date). Agent cannot fully understand tool’s output. For a calculation tool with no output schema, description should compensate with return info but does not.
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 descriptions cover both parameters (date and afterSunset) at 100%. Tool description does not add any extra meaning beyond the schema. Baseline of 3 is appropriate.
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?
Description clearly states it calculates Yahrzeit, the anniversary of death according to Hebrew calendar. Verb 'calculates' and resource 'Yahrzeit' are specific. Implicitly differentiated from sibling tools (conversion, holiday, etc.) but no explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. No description of use cases, prerequisites, or when not to use. Agent must infer from tool name alone.
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. Dates show when Glama detected each change.
7 tool updates
v0.10.3- First observed
convert-gregorian-to-hebrew - First observed
convert-hebrew-to-gregorian - First observed
daf-yomi - First observed
jewish-holidays-year - First observed
shabbat-times - First observed
torah-portion - First observed
yahrzeit
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a distinct and unique purpose: date conversion (both directions), Daf Yomi, holidays for a year, Shabbat times, Torah portion, and Yahrzeit. No two tools overlap in functionality.
Naming Consistency5/5
All tool names use lowercase with hyphens, following a clear noun-based or verb-noun structure (e.g., convert-gregorian-to-hebrew, shabbat-times). The naming is highly uniform and predictable.
Tool Count5/5
With 7 tools, the server is well-scoped for a Jewish calendar utility. Each tool addresses a common need without excess or redundancy.
Completeness4/5
Covers major Jewish calendar functions: date conversion, holidays, Shabbat times, Torah portion, Daf Yomi, and Yahrzeit. Missing a few advanced features like Molad times or specific fast day details, but covers core use cases.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Access Sefaria's library of Jewish texts, commentaries, and learning schedules via MCP
MCP server for public_holidays_mcp
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for Apple Calendar and CalDAV providers. Enables listing, creating, updating, deleting events, and checking free/busy status with per-calendar write protection.6MIT
- FlicenseNot gradedqualityCmaintenanceMCP server for the Teamup Calendar API, enabling event management, calendar listing, and available slot search.-
- FlicenseDqualityBmaintenanceMCP server for interacting with Google Calendar, enabling reading events from public calendars and, with OAuth, creating, updating, and deleting events.1-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hebcal/hebcal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server