This server provides offline business-day arithmetic, SLA due-time calculation, and cron/RRULE parsing with no network calls. All tools are pure functions that return typed results for invalid input and use bounded loops to prevent expensive requests.
Business days: Check working days, find next/previous, add/subtract business days, count business days between dates, get first/last business day of a month. Holiday-aware for ~150 countries and subdivisions (e.g., England vs. Scotland, individual US states).
SLA due time: Calculate when an N-business-hour SLA expires, counting only hours within configurable open/close times on working days; if start is outside business hours, it waits until next opening.
Cron expressions: Validate, explain in plain English, and compute up to 60 next occurrences for standard five-field cron expressions.
iCalendar RRULEs: Validate, explain, and expand recurrence rules (supporting INTERVAL, COUNT, UNTIL, BYDAY, BYMONTHDAY, BYMONTH) into up to 60 upcoming occurrences from a start date.
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., "@business-days-mcp Is 2026-12-28 a business day in the UK?"
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.
An MCP server for the date arithmetic that support, billing and operations teams actually do: is this a working day, when is this SLA due, what is the next working day after a bank holiday — plus cron and recurrence-rule parsing for the recurring side of the same job.
It runs offline. No network calls, no stored data, no model calls — every answer is computed from bundled public-holiday rules.
Business days and SLAs — holiday-aware for ~150 countries and their
subdivisions (England and Scotland differ; so do US states), via the
holidays package.
Tool | Answers |
| Is this a working day? If not, is it a weekend or a named holiday? |
| The next/last working day around a date |
| Move ±N working days from a date |
| How many working days between two dates (half-open) |
| Month boundaries |
| When does an N-business-hour SLA fall due, counting only open hours? |
Cron and recurrence — parsing only. Nothing is scheduled, stored, or executed; there are no timers and no job store. If you want something run on a schedule, this is deliberately not that tool.
Tool | Answers |
| Is this cron valid, and what does it mean in English? |
| When would it next fire? |
| Same, for an RFC 5545 RRULE |
| Expand an RRULE to its next occurrences |
Related MCP server: mcp-chrono
The hosted endpoint needs no install at all — see
Client configuration. To run it yourself, uvx
fetches and runs it:
uvx --from git+https://github.com/Vessark/business-days-mcp business-days-mcpFrom a clone:
git clone https://github.com/Vessark/business-days-mcp
cd business-days-mcp
uv sync && uv run business-days-mcp
uv run pytest # the tests are the documentationThe quickest way in. The same tools, no install, no credentials:
{
"mcpServers": {
"vessark": {
"url": "https://vessark.com/mcp"
}
}
}If you would rather not depend on someone else's uptime, run it locally — it is the same code, and it never touches the network:
{
"mcpServers": {
"business-days": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Vessark/business-days-mcp",
"business-days-mcp"
]
}
}
}// is_business_day — 2026-12-28, UK
{"date": "2026-12-28", "country": "GB"}
→ {"is_business_day": false, "reason": "holiday: Boxing Day (substitute day)"}
// sla_due_time — 8 business hours from Monday 16:00
{"start": "2026-07-27T16:00", "business_hours": 8}
→ {"due": "2026-07-28T16:00:00", "started_within_business_hours": true}
// explain_cron_expression
{"expression": "30 9 * * MON-FRI"}
→ {"explanation": "At 09:30, on Monday through Friday."}Every tool is a pure function of its arguments, which is why the test suite is mostly tables. Invalid input is an ordinary typed result, never an exception — a model that gets an argument wrong gets a readable reason and can correct itself. Every loop that a caller can influence is bounded, so no request can buy an expensive computation. Error messages never echo what you sent, so the server can't be used to relay text into someone else's agent.
Known limits, stated rather than hidden: a working week is Monday–Friday, so countries with Sunday–Thursday weeks are wrong under this assumption; holiday data covers only the years the underlying dataset knows about, and a date outside that range is refused rather than silently answered as an ordinary working day.
fbdo/business-day-mcp covers
business-day and holiday arithmetic and predates this server. If that is all
you need, use it — it also exposes timezone-aware "today" and holiday listing,
which this server does not.
This one was built for a different centre of gravity: SLA clocks that count
only business hours, and cron / RRULE parsing for the recurring side of the
same work. The overlap in the business-day tools is real and the names are
conventional; both servers are MIT licensed and both build on the excellent
holidays package.
Bump the version in both pyproject.toml and server.json, then push a
matching tag:
git tag v0.2.0 && git push origin v0.2.0That runs the test suite, checks the tag agrees with both version fields, publishes to PyPI, and republishes to the MCP registry. Both use GitHub OIDC — PyPI via Trusted Publishing — so there is no API token in this repository, in a secret store, or on any machine.
Built and maintained by Vessark. The tools in this repository are the free tier and are open source under the MIT licence. Vessark's workspace tools — the ones that operate on a connected workspace — are the commercial product and are not open source.
Issues and pull requests welcome.
Move a number of working days forward or backward from a date, skipping weekends and public holidays. Use a negative number to count backwards. Zero returns the date unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Calendar date, YYYY-MM-DD. | |
| days | Yes | Working days to move; may be negative. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it moves forward/backward, skips weekends and public holidays (implied by country/subdivision), allows negative numbers, and returns unchanged for zero. However, it does not mention any limitations like maximum range or holiday resolution details.
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?
Three short sentences, front-loaded with primary purpose. Each sentence adds value: main move, negative handling, zero case. No filler or redundant text.
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 could clarify return format (likely date string). But it covers core logic well. Context of 4 params and no enums/nesting makes this fairly complete for a calendar calculation 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?
All 4 parameters are described in the schema (100% coverage). The description adds no extra semantics beyond the schema. For example, negative 'days' is already in schema description. 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?
Description clearly states the tool moves a date by a number of business days, using 'move a number of working days forward or backward from a date'. It explicitly mentions skipping weekends and public holidays, and distinguishes from siblings like next_business_day (single day) and business_days_between (count). The verb 'move' and resource 'working days from a date' are specific.
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 versus alternatives like next_business_day or previous_business_day. The description implies general offset scenarios but does not set exclusions or prerequisites. For a tool with many date siblings, this is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts the working days between two dates, excluding weekends and public holidays. The range is half-open — the start date counts and the end date does not — so Monday to Tuesday is one working day. The result is negative when the end precedes the start.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| end_date | Yes | Calendar date, YYYY-MM-DD. | |
| start_date | Yes | Calendar date, YYYY-MM-DD. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the half-open nature and negative result behavior. However, it does not disclose the source of public holidays, potential rate limits, or whether the tool requires network access. These gaps lower transparency.
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 two sentences, front-loaded with the core purpose, and contains no redundant words. All information is pertinent and efficiently conveyed.
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 4 parameters, no annotations, and no output schema, the description is quite complete. It covers the core functionality, half-open interval, and negative results. A minor gap is the lack of mention of the holiday calendar source (e.g., defaults to US), but overall very 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?
With 100% schema description coverage, the baseline is 3. The description adds context about half-open interval and negative results, which relates to start_date and end_date, but does not add new information about country or subdivision beyond the schema. Value added is marginal.
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 counts working days between two dates, excluding weekends and public holidays. It also explains the half-open interval, distinguishing it from siblings like is_business_day or next_business_day.
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 provides basic usage context (half-open interval, negative results) but does not explicitly guide when to use this tool over siblings such as add_business_days or is_business_day. No exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a five-field cron expression into plain English. Supports ranges, lists, steps, and month or weekday names. This describes the expression; it never schedules or executes anything.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | A five-field cron expression, e.g. '30 9 * * MON-FRI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool is read-only ('never schedules or executes anything'), which is crucial for behavioral safety. It also mentions supported features (ranges, lists, steps, names). Since no annotations are provided, the description carries the full burden, and it meets it well, though it could elaborate on error handling or invalid input behavior.
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 extremely concise—two sentences that efficiently state purpose, supported features, and a critical behavioral disclaimer. No unnecessary words or repetition.
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 simplicity (single parameter, no output schema), the description is fairly complete. It explains input and behavior. However, it lacks explicit mention of the return format (plain English string), which could be inferred but is not stated. The sibling tools are similar, and the description provides enough differentiation.
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 schema has 100% coverage with a description and example for the single parameter. The description adds meaning beyond the schema by specifying that the expression is 'five-field' and supports 'ranges, lists, steps, and month or weekday names,' which guides the agent on valid input patterns.
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's purpose: 'Translate a five-field cron expression into plain English.' It uses a specific verb ('Translate') and resource ('cron expression'), and distinguishes itself from sibling tools like 'validate_cron_expression' (validation) and 'next_cron_occurrences' (computation).
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 provides clear context: it supports ranges, lists, steps, and names, and explicitly states that it 'never schedules or executes anything.' This helps differentiate from tools that might schedule or execute. However, it does not explicitly list when not to use it or name alternatives beyond the negative scheduling statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes an iCalendar recurrence rule (RRULE) in plain English. Nothing is scheduled or executed.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | An RFC 5545 recurrence rule, e.g. 'FREQ=WEEKLY;BYDAY=MO,WE'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool is non-destructive and read-only ('Nothing is scheduled or executed'). This is sufficient for a simple explanation tool, though details about the output format (plain English description) are missing.
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 extremely concise: two sentences that convey the purpose and key behavioral trait. No unnecessary 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 low complexity (single parameter, no output schema), the description covers the essential aspects: input format, action, and non-execution behavior. It differentiates from sibling tools like 'validate_recurrence_rule' and 'explain_cron_expression'. A minor gap is the lack of output description, but for a simple explanation it is acceptable.
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 coverage is 100% with a clear description of the 'rule' parameter including format and example. The tool description does not add extra meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Describes an iCalendar recurrence rule (RRULE) in plain English.' The additional sentence 'Nothing is scheduled or executed' reinforces the scope and distinguishes it from scheduling-related siblings like 'next_recurrence_occurrences'.
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 states that the tool only explains rules and does not schedule or execute anything, guiding the agent to use it for explanation purposes. It implicitly differentiates from siblings like 'explain_cron_expression' by specifying iCalendar RRULE, but does not list alternative tools for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the first working day of a given month.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| month | Yes | 1-12. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description only states the basic function without disclosing behavioral traits such as whether holidays are considered, how weekends are handled, or how parameters like 'country' and 'subdivision' affect results. This lack of detail undermines safe and effective tool selection.
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 a single sentence, achieving brevity. However, it sacrifices detail; while the sentence is front-loaded and clear, it omits necessary behavioral context. It is appropriately concise but at the expense of completeness, warranting an average score.
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 (4 parameters, no output schema, many siblings), the description is insufficiently complete. It lacks explanation of how the result is computed (e.g., shifts from first of month, holiday handling) and does not clarify the role of optional parameters. The description does not adequately support correct tool invocation.
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 75% (3 of 4 parameters have descriptions). The description adds no additional parameter semantics beyond the schema. With high coverage, the baseline is 3, and no extra value is provided, so the score remains 3.
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's function: 'Returns the first working day of a given month.' The verb 'returns' specifies the action, and the resource 'first working day' is distinct from siblings like 'last_business_day_of_month' and 'next_business_day'. It directly conveys the purpose without ambiguity.
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 provides no guidance on when to use this tool versus alternatives. With 13 sibling tools, the agent receives no hints about context, prerequisites, or when not to use it. The usage must be inferred entirely from the tool name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns whether a date is a working day, accounting for weekends and public holidays in the given country or subdivision.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Calendar date, YYYY-MM-DD. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It does not disclose any behavioral traits beyond the core function, such as whether external holiday data is used, any authentication needs, rate limits, or side effects. The description is minimal.
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 a single, front-loaded sentence that conveys the essential purpose without any wasted words. It is appropriately sized for the tool's simplicity.
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 boolean-returning tool with no output schema, the description covers the main purpose. However, since no output schema exists, the agent might benefit from explicit mention of the return value (true/false). Still, the context is largely complete given the tool's straightforward nature.
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 coverage is 100% (all three parameters have descriptions in the schema). The description adds some context by mentioning weekends and public holidays, which connects to the country parameter. However, it does not add significant new meaning beyond the schema's parameter descriptions.
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 returns a boolean indicating whether a date is a working day, accounting for weekends and public holidays. It uses a specific verb ('Returns') and resource ('working day'), and distinguishes it from sibling tools that compute next/previous business days or ranges.
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 when checking a single date's business day status, but does not explicitly provide when-not-to-use guidance or mention alternative siblings (like 'next_business_day' or 'business_days_between'). No exclusions or context on when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the last working day of a given month.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| month | Yes | 1-12. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like holiday handling via country/subdivision. It only says 'working day' without clarification, and output format is unspecified.
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?
Single sentence with no extraneous words. Front-loads the core action efficiently.
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 4 parameters and no output schema or annotations, the description omits return format, holiday logic, and usage examples. Incomplete for a tool with many 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?
Schema description coverage is 75% (3 of 4 parameters described). The description adds no extra parameter context beyond the schema, so baseline score applies.
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 returns the last working day of a given month, with a specific verb and resource. It effectively distinguishes from siblings like 'first_business_day_of_month'.
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 guidance is provided on when to use this tool versus alternatives. Context such as comparing with other business day tools is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the first working day after a date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Calendar date, YYYY-MM-DD. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavior such as returning the same date if already a business day, handling of weekends/holidays, or the effect of country/subdivision parameters.
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?
Single sentence with no wasted words, but under-specified. Loses a point for missing critical context.
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 3 parameters, localization support, and many sibling tools, the description is too brief. Lacks explanation of default holiday calendar, behavior for non-business days, and relationship to other tools.
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 100%, so baseline is 3. Description adds no extra information beyond what the schema already provides for each parameter.
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 verb 'Find', resource 'first working day', and constraint 'after a date'. It effectively distinguishes from sibling tools like 'previous_business_day' and 'is_business_day'.
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 guidance on when to use this tool vs siblings (e.g., when to use 'next_business_day' vs 'add_business_days'). No prerequisites or edge-case handling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes when a five-field cron expression would next fire after a given start time, returning up to 60 timestamps. A pure calculation over the expression: no job is created, stored, or executed.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many occurrences to return, 1-60. Defaults to 5. | |
| start | Yes | Occurrences are computed after this, e.g. 2026-07-27T09:00. | |
| expression | Yes | A five-field cron expression, e.g. '30 9 * * MON-FRI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides key behavioral info: pure calculation, no side effects, up to 60 timestamps. But lacks details on error handling (invalid expression, timezone) and what happens if no future occurrences exist. Adequate but not comprehensive.
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, no fluff. Front-loaded with the core functionality. Every word contributes to understanding.
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?
Covers necessary aspects for a simple computation tool: purpose, input, output scope. Could mention error behavior or timezone but not critical. Given no output schema or annotations, it's reasonably complete.
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 coverage is 100%, so the description adds little beyond the schema. It reinforces that 'start' is after which occurrences are computed and that expression is five-field. 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?
Clear verb ('computes') and resource ('five-field cron expression') specified. Distinguishes from siblings by emphasizing it's a pure calculation with no side effects. The description explicitly mentions the action, input, and output format.
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?
Implicitly states when to use via 'no job is created, stored, or executed' but doesn't explicitly list alternatives or when not to use. However, the context of sibling tools like 'validate_cron_expression' is clear, so a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand an iCalendar recurrence rule (RRULE) into its next occurrences from a start date and time, honouring INTERVAL, COUNT, UNTIL, BYDAY, BYMONTHDAY, and BYMONTH. A pure calculation: it creates no schedule, stores nothing, and runs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | An RFC 5545 recurrence rule, e.g. 'FREQ=WEEKLY;BYDAY=MO,WE'. | |
| count | No | How many occurrences to return, 1-60. Defaults to 5. | |
| start | Yes | Occurrences begin at or after this, e.g. 2026-07-27T09:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool is a pure calculation with no side effects (creates no schedule, stores nothing, runs nothing) and lists the RRULE features it honours. This provides sufficient transparency for a simple computation 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?
The description is two sentences with no wasted words. The first sentence states the core purpose and supported features, while the second clarifies side-effect-free behavior. Perfectly front-loaded and efficient.
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 simplicity (no output schema, no nested objects), the description covers purpose, supported features, and behavioral transparency. It omits output format and timezone handling, but for a straightforward computation tool, this is adequate. The pure calculation statement adds valuable context.
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 coverage is 100% with each parameter described. The description adds minimal extra meaning: it only reiterates the RRULE features for the 'rule' parameter and does not enhance understanding of 'count' or 'start' beyond the schema. Baseline of 3 is appropriate since schema already does the heavy lifting.
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 expands an iCalendar recurrence rule into next occurrences from a start date and time, specifically naming supported RRULE parts (INTERVAL, COUNT, etc.). It distinguishes itself from sibling tools like explain_recurrence_rule (explanation) and validate_recurrence_rule (validation) by focusing on computation.
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 when you need to compute future occurrences without side effects, stating 'creates no schedule, stores nothing, and runs nothing.' While it does not explicitly say when not to use or list alternatives, the context of sibling tools (e.g., explain_cron_expression, validate_recurrence_rule) helps differentiate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the last working day before a date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Calendar date, YYYY-MM-DD. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'Find,' suggesting a read operation, but does not explain how business days are determined, whether it considers holidays, or if the operation is idempotent.
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 a single, clear sentence with no unnecessary words. It is front-loaded and easy to parse.
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?
The tool has 3 parameters and no output schema. The description is minimal and does not explain the return value or how holidays are handled. Acceptable for a simple tool but lacks completeness.
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 has 100% description coverage, so the description adds no additional meaning beyond the schema. Baseline score of 3 applies as the description does not enhance parameter semantics.
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 verb 'Find' and the resource 'last working day before a date,' distinguishing it from sibling tools like next_business_day or is_business_day.
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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out when a service-level agreement falls due, counting only business hours on working days. If the clock starts outside business hours it waits until the next working day opens. Business hours default to 09:00-17:00 and times are wall-clock in the calendar's own locality.
| Name | Required | Description | Default |
|---|---|---|---|
| opens | No | Opening time, HH:MM. Defaults to 09:00. | |
| start | Yes | When the clock starts, e.g. 2026-07-27T09:00. | |
| closes | No | Closing time, HH:MM. Defaults to 17:00. | |
| country | No | ISO 3166-1 alpha-2 country code. Defaults to US. | |
| subdivision | No | Optional subdivision code, e.g. SCT. | |
| business_hours | Yes | How many business hours are allowed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: counting only business hours, waiting outside hours, default hours, and locality. However, it fails to specify the return format (e.g., a datetime string).
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, front-loaded with purpose, no redundancy. 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?
Missing output schema and no description of return value or error conditions. For a tool with 6 parameters and no annotation support, more detail is needed.
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 coverage is 100% (baseline 3). The description adds context about default behavior (09:00-17:00, wall-clock locality), enriching understanding beyond schema definitions.
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 computes SLA due time using business hours and working days, distinguishing it from sibling tools like next_business_day or add_business_days.
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?
It describes when to use (SLA due time), but does not explicitly exclude alternatives or mention when not to use it, though implied by its specific function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a five-field cron expression is syntactically valid. Parsing only; nothing is scheduled or run.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | A five-field cron expression, e.g. '30 9 * * MON-FRI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It confirms no side effects ('nothing is scheduled or run') and that it is only syntactic validation. Could add detail on return format, but is sufficient for a simple check.
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 that front-load the core purpose and immediately clarify the limitation. No 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?
For a simple validation tool with one parameter and no output schema, the description is complete. It covers what it does, what it doesn't do, and the expected input format.
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 parameter 'expression' is fully described in the schema with an example. The description adds the context of 'five-field' cron expression, which complements the schema perfectly.
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 checks whether a five-field cron expression is syntactically valid, using a specific verb and resource. It distinguishes itself from sibling tools that explain or compute occurrences.
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 'Parsing only; nothing is scheduled or run,' which tells when to use it (for validation only) and when not to (for actual scheduling or execution).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an iCalendar recurrence rule (RRULE) is valid and supported. Parsing only; nothing is scheduled.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | An RFC 5545 recurrence rule, e.g. 'FREQ=WEEKLY;BYDAY=MO,WE'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It states 'Parsing only; nothing is scheduled,' indicating no side effects. However, it does not disclose the return format (e.g., boolean vs errors) or what 'supported' entails.
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 two sentences, front-loaded with the primary purpose, and contains no superfluous information. Every word contributes 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?
For a simple validation tool with one parameter, the description is nearly complete. The missing output schema is a gap, but the context signal of 'no output schema' is noted. The 'nothing is scheduled' detail adds important context.
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 schema covers the single parameter 'rule' with 100% description coverage. The tool description adds no additional semantic info beyond the schema's example and format specification.
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 validates iCalendar recurrence rules (RRULE) for validity and support, and emphasizes it is parsing-only with no scheduling. This distinguishes it from sibling tools like 'explain_recurrence_rule' and 'next_recurrence_occurrences'.
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 the tool is for validation via 'Check whether ... is valid', but does not explicitly state when to use it over siblings or when not to use it. No alternatives or exclusions are provided.
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. Dates show when Glama detected each change.
v0.1.0add_business_daysbusiness_days_betweenexplain_cron_expressionexplain_recurrence_rulefirst_business_day_of_monthis_business_daylast_business_day_of_monthnext_business_daynext_cron_occurrencesnext_recurrence_occurrencesprevious_business_daysla_due_timevalidate_cron_expressionvalidate_recurrence_ruleEach tool targets a distinct function: cron vs. recurrence rule vs. business day queries. Tools like next_cron_occurrences and next_recurrence_occurrences are clearly differentiated by input type, and no two tools have overlapping purposes.
All tools follow a consistent verb_noun pattern in snake_case (e.g., explain_cron_expression, next_business_day, validate_cron_expression). No mixed conventions or vague verbs.
14 tools is well-scoped for the domain, covering both calendar recurrence patterns and business day arithmetic without bloat. Each tool earns its place.
The tool surface covers all key operations: validation, explanation, occurrence calculation for cron and RRULE; and full business day functions (is, next, previous, add, count, first/last of month, SLA due time). No obvious gaps.
Deterministic date arithmetic with auditable receipts: business days, due dates, holidays.
Zero-signup business-day date-math API: add days, count days between dates, is-business-day.
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Business days, meeting overlap and recurrence expansion, deterministic. 3 of 5 tools free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vessark/business-days-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
