Skip to main content
Glama

Find long weekends

find_long_weekends
Read-onlyIdempotent

Find long weekends: 3+ consecutive days off made of weekends and public holidays in the country (e.g. Japan's Golden Week, China's National Day Golden Week). Give a year, or from (default today) to list upcoming ones.

Input Schema

NameRequiredDescriptionDefault
fromNoList long weekends ending on or after this date (default: today in the country).
yearNo
limitNo
regionNoOutside Japan: state/province code (ISO 3166-2 suffix, e.g. CA for California) to include regional holidays.
countryNoISO 3166-1 alpha-2 country code (e.g. US, GB, DE, CN, JP). Defaults to JP (Japan) when omitted.JP
min_lengthNo
include_governmentNoOutside Japan: also treat days off only for government offices (e.g. Indonesia's cuti bersama, Canadian federal holidays) as days off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code (e.g. JP, US, CN, GB). Default JP."New value: +"ISO 3166-1 alpha-2 country code (e.g. US, GB, DE, CN, JP). Defaults to JP (Japan) when omitted."
    • changedInput schema / properties / from / description
      Previous value: -"List long weekends ending on or after this date (default: today in Japan)."New value: +"List long weekends ending on or after this date (default: today in the country)."
  2. Changed1 schema field changed
    • addedInput schema / properties / include_government
      Added value: +{
      +  "default": false,
      +  "description": "Outside Japan: also treat days off only for government offices (e.g. Indonesia's cuti bersama, Canadian federal holidays) as days off.",
      +  "type": "boolean"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / country
      Added value: +{
      +  "default": "JP",
      +  "description": "ISO 3166-1 alpha-2 country code (e.g. JP, US, CN, GB). Default JP.",
      +  "pattern": "^[A-Za-z]{2}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / region
      Added value: +{
      +  "description": "Outside Japan: state/province code (ISO 3166-2 suffix, e.g. CA for California) to include regional holidays.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral context: the 3+ day definition, that weekends and public holidays are combined, and that `from` defaults to today in the country. It does not mention pagination, ordering, or return format, but those are minor for a read-only lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core definition front-loaded, followed by usage guidance. Examples are brief and illustrative; there is no wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter read-only computation tool with good annotations and no output schema, the description covers the core concept, key inputs (year/from), and default behavior sufficiently. It could more fully address the optional parameters (region, min_length, include_government), but the schema carries enough of that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 57%, so some parameters (from, region, country, include_government) are already documented. The description adds meaning for `year` and `from` (default today) but says nothing about `limit`, `min_length`, `region`, or `include_government` beyond what the schema provides, leaving gaps for those parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Find long weekends') and precisely defines the concept as '3+ consecutive days off made of weekends and public holidays in the country', with illustrative examples (Golden Week, National Day Golden Week). This distinguishes it from siblings like list_holidays or business_days without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear input guidance ('Give a year, or from (default today) to list upcoming ones'), implicitly explaining how to get either a specific year's long weekends or a forward-looking list. However, it does not explicitly name alternative tools or state when not to use this one, leaving the agent to infer the distinction from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources