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., "@vic-au-important-dates-mcp What are the public holidays in Victoria 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.
A Model Context Protocol (MCP) server that provides access to Victoria, Australia's important dates and holidays API.
The API is documented here
Access to Victoria, Australia public holidays and important dates
MCP-compatible server implementation
Easy integration with MCP clients
RESTful API wrapper for Victoria government data
Related MCP server: business-day-mcp
pip install vic-au-important-dates-mcpAfter installation, you can run the MCP server directly:
vic-au-dates-mcp-serverOr using uv:
uv run vic-au-dates-mcp-serverfrom vic_au_important_dates_mcp.client import VictoriaImportantDatesClient
# Create a client instance
client = VictoriaImportantDatesClient()
# Get holidays for a specific year
holidays = client.get_holidays(2024)
# Get holidays for a specific date range
holidays = client.get_holidays_range("2024-01-01", "2024-12-31")The package uses environment variables for configuration:
DEVELOPER_VIC_GOV_AU_KEY:
DEVELOPER_VIC_GOV_AU_SECRET:
BASE_URL (The current known URL is https://wovg-community.gateway.prod.api.vic.gov.au/vicgov/v2.0/ and is subject to change in the future )
Register at [developer.vic.gov.au][https://developer.vic.gov.au] to get your developer key/secret
MIT License - see LICENSE file for details.
Contributions are welcome! Please feel free to submit a Pull Request.
For issues and questions, please use the GitHub issues page.
Get a list of important dates for the state of Victoria, Australia.
Args:
from_date: From date in the format YYYY-MM-DD
to_date: To date in the format YYYY-MM-DD
type: can be one of PUBLIC_HOLIDAY,DAYLIGHT_SAVING,SCHOOL_TERM,SCHOOL_HOLIDAY,FLAG_NOTIFICATION,PARLIAMENT_SITTING,MULTI_FAITH
| Name | Required | Description | Default |
|---|---|---|---|
| from_date | Yes | ||
| to_date | Yes | ||
| type | No | PUBLIC_HOLIDAY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds value by defining parameter patterns but does not state that the tool is a read-only operation, mention rate limits, or describe side effects. The description partially compensates but lacks full 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 concise with no wasted words. It uses a clear 'Args' list, front-loads the purpose, and every sentence is necessary.
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 no output schema, and the description does not explain what the tool returns (e.g., format of dates, list vs. single entry). It also lacks a statement that it is a read operation. Given the complexity (3 params, no output schema), the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by specifying the exact format for from_date and to_date (YYYY-MM-DD) and listing all valid type values. This adds critical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'important dates for the state of Victoria, Australia', specifying the resource and scope. It uses a specific verb ('Get') and distinguishes itself from potential siblings by focusing on Victorian dates.
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 for parameter usage (date formats and type options), making it easy for the agent to construct valid requests. However, it does not mention when to use this tool versus alternatives or any constraints like required auth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3get_datesScored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. The single tool's purpose is clearly defined.
With a single tool, there is no pattern to assess inconsistency. The name 'get_dates' follows a clear verb_noun structure.
The server has only one tool, which is at the low end of typical scoping. While the tool covers many date types via parameters, a slightly larger set (e.g., separate tools for each type) might be more intuitive, but it remains functional.
The tool fully covers the stated domain of important dates for Victoria, Australia, supporting all listed date types (public holidays, daylight saving, school terms, etc.) with flexible date filtering. No obvious gaps exist for a read-only query service.
MCP server for public_holidays_mcp
Holidays MCP — wraps Nager.Date API (free, no auth)
Nager.Date Public Holidays MCP.
Australian public data as MCP tools: incidents, gauges, declarations, industry calendars, archive.