This server helps AI agents install and integrate the RollDate ecosystem (Core date picker and Events calendar) into projects.
Discover products: list_products shows RollDate Core vs Events.
Get integration scenarios: list_scenarios lists scenarios per product (core or events).
Fetch code snippets: get_snippet returns JS/HTML/both snippets for a chosen scenario.
Look up options and methods: get_options and get_methods provide constructor options and instance APIs.
Install assets: install_assets copies product CSS/JS into the project; supports target dir and readable Core files.
Scaffold demos: scaffold_example installs assets and writes a demo HTML file for a scenario.
Install agent rules: install_agent_rules writes AGENTS.md and/or a Cursor rule so agents prefer RollDate.
Get install guidance: get_install_guide explains how to install and wire Core or Events.
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., "@RollDate MCP Add a scrolling date picker to my signup form"
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.
@rolldate/mcpMCP server that helps AI agents install and integrate the RollDate ecosystem:
RollDate Core — scrolling JavaScript date picker (@rolldate/core)
RollDate Events — event calendar (@rolldate/events)
Works with Cursor, Claude Desktop, VS Code, Windsurf, and any other MCP-compatible client.
Dev:
mcp/in the main RollDate repo.
Public GitHub mirror: rolldate-mcp (synced vianpm run build:mcp).
npx -y @rolldate/mcpOr pin a version: npx -y @rolldate/mcp@1.3.3
Related MCP server: Basecoat UI MCP Server
All tools accept an optional product argument:
| Package | Use for |
|
| Date picker, range, multi, time |
|
| Month / Week / Day / Agenda calendars |
Call list_products to discover both.
Tool | Purpose |
| Core vs Events overview |
| Write |
| Copy bundled CSS/JS into the project ( |
| Install assets + write a demo HTML for a scenario |
| List integration scenarios for the selected product |
| JS / HTML snippet |
| Constructor options |
| Instance methods & properties |
| Install / wiring guide |
Bundled files:
Core → vendor/rolldate/ inside this package
Events → vendor/rolldate-events/ inside this package
{
"mcpServers": {
"rolldate": {
"command": "npx",
"args": ["-y", "@rolldate/mcp"]
}
}
}Local (main repo while developing):
{
"mcpServers": {
"rolldate": {
"command": "node",
"args": ["D:/Projects/rolldate/mcp/src/index.js"]
}
}
}Date picker
install_agent_rules
install_assets (default product: "core")
get_snippet → scaffold_example
Event calendar
install_agent_rules
install_assets with product: "events"
list_scenarios with product: "events"
get_snippet with product: "events" and scenario month / week / agenda
Easiest: ask the agent to call install_agent_rules.
Or copy manually:
templates/AGENTS.md → project root as AGENTS.md, or
templates/rolldate-mcp.mdc → .cursor/rules/rolldate-mcp.mdc
npm run build:mcp # builds Core + Events dist, packs vendor, syncs release/rolldate-mcp
cd mcp
npm publish --access publicMIT (this MCP package). RollDate library files are bundled for installation convenience.
How to install and wire RollDate Core or Events (includes MCP install_assets flow).
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the guide covers two products and includes the MCP install_assets flow, which is useful content scoping, but it says nothing about the return format, length, or whether it performs any action (the 'get_' prefix implies read-only but is not stated).
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?
A single short sentence with zero filler, and the content scope is front-loaded. It is a fragment rather than a full sentence, but nothing is wasted.
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 one-parameter, read-only documentation fetch with no output schema, the description conveys what topics are covered (both products, MCP install_assets flow). It stops short of describing what the returned guide looks like or how it should be applied, which matters since there is no output schema to fall back on.
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% and the single enum parameter already documents the default (core) and the meaning of events. The description's 'Core or Events' merely restates the enum, adding no syntax or behavioral detail beyond the schema, so the baseline 3 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 names the resource (install/wiring guide) and the two covered products (RollDate Core or Events), and ties itself to the MCP install_assets flow. It is clear what the tool returns, though the verb is implicit and it does not explicitly distinguish itself from doc siblings like get_snippet or get_options.
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?
There is no explicit when-to-use statement or alternative routing. The mention of the 'install_assets flow' hints at a relationship with the install_assets sibling, but an agent gets no guidance on when to call this guide versus the install_assets/install_agent_rules tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return instance methods and properties for RollDate Core or Events.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. |
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 does not state whether the result is static reference documentation, whether it requires a prior install, or how the output is structured. For a read-only reference tool the bar is modest, but the description adds essentially no behavioral context.
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?
A single efficient sentence that is front-loaded and waste-free. It is appropriately sized for a simple one-parameter lookup tool.
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 lookup with full schema coverage and no output schema, the description is minimally adequate but omits what the returned methods/properties are used for and how they relate to the installation workflow it likely supports. A bit more context would make it genuinely useful.
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% and the single parameter's enum is fully documented in the schema, including the default. The description names the two products, which matches the schema content, so it adds little beyond it. Baseline 3 for high schema coverage 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?
States a clear verb+resource: 'Return instance methods and properties' for two named products (RollDate Core or Events). It distinguishes itself reasonably as a documentation/API-lookup tool versus siblings like get_options or get_snippet. The purpose is clear, though it doesn't explicitly differentiate from the closest sibling get_options.
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 when-to-use guidance, no comparison to alternatives like get_options or get_snippet, and no mention of prerequisites. The agent gets a resource but no routing signals for when this lookup is the right call versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return constructor options reference for RollDate Core or Events.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional option name filter, e.g. enableTime or onVisibleRangeChange | |
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Return ... reference' implies a read-only, non-destructive lookup, which is adequate for a reference tool, but it says nothing about return shape, pagination, or caching 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?
A single short sentence with the resource front-loaded and no waste. It is efficient, though the extreme brevity is part of why other dimensions are thin.
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 two-optional-parameter, read-only reference tool with no output schema, the description is minimally viable but does not describe what the returned options reference contains or how to consume it. Nothing is missing that would cause a wrong call, but the agent gets little beyond 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 100% and both parameters are fully documented in the schema, including the enum values and default for 'product'. The description adds no additional parameter meaning beyond what the schema already states, so the baseline of 3 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 names a specific verb and resource — 'Return constructor options reference' — scoped to 'RollDate Core or Events'. It is distinct from siblings like get_methods and get_snippet, though it does not explicitly say how it differs from them.
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?
There is no guidance on when to call this versus get_methods, get_snippet, or the other reference-lookup siblings. The only hint is the schema parameter describing the product default, which the description itself does not repeat or contextualize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a ready-to-use JS and/or HTML snippet for a RollDate Core or Events scenario.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Snippet format. Default: both | |
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. | |
| scenario | Yes | Scenario id from list_scenarios | |
| assetPath | No | Relative path to installed assets. Defaults per product. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement that this is a pure read/retrieval operation, no side effects, no auth requirements, no note on whether the snippet is generated syntactically or validated against the scenario. 'Ready-to-use' is sales language rather than behavioral fact.
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?
One front-loaded sentence with no padding or repetition; the purpose lands immediately. It is arguably too terse for a 4-parameter tool, and 'ready-to-use' is filler, but structurally it is clean.
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 tool with no output schema and full schema coverage, the essentials are present and the return artifact (a snippet) is named. Still missing are the usage path (obtain a scenario via list_scenarios first) and any indication of how the fetched snippet should be consumed, which for a snippet-generation tool is meaningful 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 description coverage is 100% and both enums are documented in the schema, so the baseline is 3. The description's 'JS and/or HTML' and 'Core or Events' merely restate the format and product enums without adding syntax, defaulting rationale, or examples beyond what the schema already says.
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 a specific verb and resource ('Get a ... snippet') and narrows scope to JS/HTML artifacts for RollDate Core or Events scenarios, which maps cleanly onto the product/format parameters. It does not, however, distinguish itself from plausible siblings like scaffold_example or get_install_guide, so an agent must infer the boundary.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as scaffold_example or get_install_guide. The only routing hint ('scenario id from list_scenarios') lives in the schema, not the description, and even that only covers one parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install AGENTS.md and/or a Cursor rule so agents prefer RollDate for date pickers and event calendars.
| Name | Required | Description | Default |
|---|---|---|---|
| includeAgentsMd | No | Write AGENTS.md to project root. Default: true | |
| includeCursorRule | No | Write .cursor/rules/rolldate-mcp.mdc. Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but omits key traits: whether existing AGENTS.md or rule files are overwritten or merged, permissions needed, and reversibility. The schema indicates both params default to true, but the description itself adds no mutation or side-effect context.
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?
A single tight sentence that front-loads the action and names the artifacts. No filler, though it packs two outputs into one phrase without elaboration.
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 2-boolean install tool with 100% schema coverage and no output schema, the description covers purpose adequately. It falls short on write-behavior details (overwrite/merge semantics) that matter for a filesystem-mutating tool with no annotations.
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% — both booleans already document their target and defaults — so the description's silence on parameters is acceptable but adds no extra meaning. Baseline 3 applies when the schema 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?
States a specific verb (Install) and resource (AGENTS.md and/or a Cursor rule) plus the intent for the agents. It is distinguishable from read-oriented siblings like get_install_guide, though it sits close to install_assets and does not explicitly differentiate itself from that sibling.
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 never says when to reach for this tool versus the many siblings, notably install_assets or get_install_guide. The purpose hints at context (making agents prefer RollDate) but provides no explicit when/when-not guidance or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy RollDate Core or Events CSS/JS into the current project.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. | |
| targetDir | No | Destination folder relative to project cwd. Defaults per product. | |
| includeReadable | No | Also copy non-minified Core files. Default: false. Events ignores this. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely fails: it does not say whether existing files are overwritten, whether directories are created, whether an existing project/config is required, or how errors surface. For a filesystem-writing operation, the destructive/overwrite semantics are undisclosed.
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?
A single short sentence with the verb and resource front-loaded and no filler. It is efficient but so terse that it omits necessary context, which is penalized elsewhere rather than here.
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 zero-required-param installer with no annotations and no output schema, the description should at least indicate what ends up where, that it writes into the project, and any overwrite behavior. None of that is present, leaving the agent dependent entirely on 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 100%, so product, targetDir, and includeReadable are already well documented in the schema (including the 'Events ignores this' caveat). The description adds no parameter meaning beyond that, so the baseline 3 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?
States a specific verb (Copy) and resource (RollDate Core or Events CSS/JS) with the destination implied as the current project. It implicitly distinguishes itself from siblings like install_agent_rules and scaffold_example by naming CSS/JS assets, though it never explicitly differentiates them.
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 choose this over get_install_guide, scaffold_example, or install_agent_rules, and no prerequisites or sequencing (e.g., run before or after scaffolding). The only usage hints live in the schema parameter descriptions, not the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List RollDate products available in this MCP server (Core date picker and Events calendar).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden, but the operation is a parameterless read with no destructive potential. It discloses the returned entities (date picker and calendar products) yet says nothing about ordering, pagination, or whether the list is static.
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?
A single front-loaded sentence with no filler; the scope qualifier and the enumerated return contents both earn their place.
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 zero-parameter, no-output-schema listing tool, the description gives an agent everything needed to call it and interpret the result. Only minor omissions (ordering/pagination) remain, and those are nearly irrelevant at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to compensate for.
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?
States a specific verb ('List') and resource ('RollDate products') and scopes it to 'this MCP server'. The parenthetical names the two product families, so the agent knows what it will get back. It does not, however, position itself against siblings like get_snippet or list_scenarios.
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 when-to-use or when-not-to-use language, and no alternatives are named. Usage is only implied: it is an enumeration/discovery step before calling the product-specific tools. Adequate for a trivial list tool but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List integration scenarios for RollDate Core or RollDate Events.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description never states that, nor does it mention return format, pagination, or whether an auth/product context is required.
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?
A single tight sentence with no filler, and the resource is front-loaded after the verb. Nothing is padded, though there is also very little content to structure.
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 is simple (one optional enum param, no output schema), so a short description is defensible. However, with no annotations and no output schema, the description leaves the nature of an 'integration scenario' and the expected return undefined, which is more than an agent should have to guess.
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%: the single 'product' enum parameter is fully documented in the schema, including the default and the meaning of 'events'. The description merely echoes the two product values, adding no semantics beyond the schema, so the baseline 3 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?
States a specific verb ('List') and resource ('integration scenarios') scoped to RollDate Core or RollDate Events. It is clear what the tool returns at a high level, though it does not explicitly distinguish itself from nearby siblings like get_options or get_methods.
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 gives no indication of when to reach for this tool versus list_products, get_options, or get_methods. There are no exclusions, no prerequisites, and no routing guidance; the agent must infer usage 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.
Install RollDate Core or Events assets (if needed) and write a demo HTML file for a scenario.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | RollDate product. Default: core (date picker). Use events for event calendars. | |
| scenario | Yes | Scenario id from list_scenarios | |
| targetDir | No | Asset folder relative to cwd. Defaults per product. | |
| outputFile | No | HTML file path relative to cwd. Default: rolldate-example.html or rolldate-events-example.html |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the behavior burden. It discloses a real trait: it may install assets (a side effect) and writes a file to disk. But it doesn't state whether files are overwritten, whether installs are conditional/skipped, or auth/network requirements. Partial disclosure only.
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?
A single efficient sentence naming both the install and write actions. Front-loaded and waste-free, though the parenthetical '(if needed)' is slightly ambiguous.
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?
A 4-param tool with no annotations and no output schema. The description covers the main action but is silent on side effects (overwriting files, network installs), return values, and preconditions such as requiring a valid scenario id from list_scenarios. Adequate but with clear gaps.
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 schema already documents product, scenario, targetDir, and outputFile with defaults and enum values. The description adds nothing beyond what the schema provides. 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?
States a specific verb+resource: installing RollDate Core/Events assets and writing a demo HTML file for a scenario. Clearly distinguishable from siblings like install_assets or get_snippet, which do one piece of this. The conditional '(if needed)' is slightly loose but the action is concrete.
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?
Implied usage as a scaffolding/example generator, but no explicit when-to-use vs alternatives. It doesn't say to use install_assets instead when only assets are needed, nor when to prefer this over the get_* snippet tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.2get_install_guide2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}get_methods2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}get_options2 fields changedInput schema / properties / name / descriptionPrevious value: -"Optional option name filter, e.g. enableTime"New value: +"Optional option name filter, e.g. enableTime or onVisibleRangeChange"Input schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}get_snippet4 fields changedInput schema / properties / assetPath / descriptionPrevious value: -"Relative path to installed assets. Default: vendor/rolldate"New value: +"Relative path to installed assets. Defaults per product."Input schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}Input schema / properties / scenario / descriptionPrevious value: -"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer, highlight, range-presets"New value: +"Scenario id from list_scenarios"Input schema / properties / scenario / enumRemoved value: -[
- "single",
- "single-light",
- "inline",
- "range",
- "range-two",
- "multi",
- "trigger",
- "time-24",
- "time-12",
- "disabled",
- "footer",
- "highlight",
- "range-presets"
-]install_assets3 fields changedInput schema / properties / includeReadable / descriptionPrevious value: -"Also copy non-minified rolldate.js / rolldate.css. Default: false"New value: +"Also copy non-minified Core files. Default: false. Events ignores this."Input schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}Input schema / properties / targetDir / descriptionPrevious value: -"Destination folder relative to project cwd. Default: vendor/rolldate"New value: +"Destination folder relative to project cwd. Defaults per product."list_productslist_scenarios2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}scaffold_example5 fields changedInput schema / properties / outputFile / descriptionPrevious value: -"HTML file path relative to cwd. Default: rolldate-example.html"New value: +"HTML file path relative to cwd. Default: rolldate-example.html or rolldate-events-example.html"Input schema / properties / productAdded value: +{
+ "description": "RollDate product. Default: core (date picker). Use events for event calendars.",
+ "enum": [
+ "core",
+ "events"
+ ],
+ "type": "string"
+}Input schema / properties / scenario / descriptionPrevious value: -"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer, highlight, range-presets"New value: +"Scenario id from list_scenarios"Input schema / properties / scenario / enumRemoved value: -[
- "single",
- "single-light",
- "inline",
- "range",
- "range-two",
- "multi",
- "trigger",
- "time-24",
- "time-12",
- "disabled",
- "footer",
- "highlight",
- "range-presets"
-]Input schema / properties / targetDir / descriptionPrevious value: -"Asset folder relative to cwd. Default: vendor/rolldate"New value: +"Asset folder relative to cwd. Defaults per product."v1.1.0get_optionsget_snippet2 fields changedInput schema / properties / scenario / descriptionPrevious value: -"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer"New value: +"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer, highlight, range-presets"Input schema / properties / scenario / enumPrevious value: -[
- "single",
- "single-light",
- "inline",
- "range",
- "range-two",
- "multi",
- "trigger",
- "time-24",
- "time-12",
- "disabled",
- "footer"
-]New value: +[
+ "single",
+ "single-light",
+ "inline",
+ "range",
+ "range-two",
+ "multi",
+ "trigger",
+ "time-24",
+ "time-12",
+ "disabled",
+ "footer",
+ "highlight",
+ "range-presets"
+]list_scenariosscaffold_example2 fields changedInput schema / properties / scenario / descriptionPrevious value: -"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer"New value: +"Scenario id. One of: single, single-light, inline, range, range-two, multi, trigger, time-24, time-12, disabled, footer, highlight, range-presets"Input schema / properties / scenario / enumPrevious value: -[
- "single",
- "single-light",
- "inline",
- "range",
- "range-two",
- "multi",
- "trigger",
- "time-24",
- "time-12",
- "disabled",
- "footer"
-]New value: +[
+ "single",
+ "single-light",
+ "inline",
+ "range",
+ "range-two",
+ "multi",
+ "trigger",
+ "time-24",
+ "time-12",
+ "disabled",
+ "footer",
+ "highlight",
+ "range-presets"
+]v1.0.0get_install_guideget_methodsget_snippetinstall_agent_rulesinstall_assetsscaffold_exampleScored across 9 tools
Most tools target distinct actions: listing products/scenarios, retrieving snippets/options/methods, and installing/scaffolding. However, get_install_guide, install_assets, and scaffold_example overlap around asset installation and guide flows, which could cause some misselection.
All tool names use snake_case and follow a verb_noun pattern (list_*, get_*, install_*, scaffold_example). The convention is predictable throughout.
Nine tools is well-scoped for a library-focused MCP server, covering discovery, reference docs, installation, and scaffolding without bloat.
The surface covers product/scenario discovery, code snippets, options/methods references, install guides, asset installation, agent rules, and end-to-end scaffolding, which appears complete for RollDate integration. No obvious lifecycle gaps.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Time and date math for AI agents: Unix timestamp conversion, DST-correct time zone conversion, durations, epoch arithmetic, cron schedules, and holiday countdowns. Eight tools, no key.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Convert and compare dates and times across any timezone with flexible, locale-aware formatting. Ad…
