Skip to main content
Glama

Urlaub Smart

by de.urlaub-smart
OverviewDiscussionsAdmin

Server Details

Plan vacation days around public holidays, bridge days and school holidays in DE, AT and CH

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation3/5

best_bridge_days and plan_vacation both return optimal booking days based on public holidays and weekends, with similar outputs such as booking dates, factors, markdown tables, and URLs. The descriptions offer some differentiation (top six levers vs. full plan), but the boundary is still blurry; the other three tools are clearly distinct.

Naming Consistency3/5

All names use snake_case, but the grammatical patterns are mixed: list_regions and plan_vacation follow verb_noun, while best_bridge_days, childcare_gap, and public_and_school_holidays are noun/adjective phrases. They remain readable but do not follow a predictable single convention.

Tool Count5/5

Five tools is well-scoped for a focused vacation-planning service. Each tool maps to a meaningful capability: region lookup, holiday data, vacation planning, bridge-day suggestions, and childcare gap analysis.

Completeness4/5

The core read-only workflows are covered: discovering regions, retrieving public and school holidays, optimizing vacation days, suggesting bridge days, and assessing childcare coverage. Minor gaps such as region comparison or direct holiday lookup by date exist but are not critical for the stated domain.

Available Tools

5 tools
best_bridge_daysBest bridge days and leversAInspect

The six best non-overlapping vacation levers of a year for a region: classic bridge days (1 vacation day → 4 days off) and holiday clusters (e.g. 4 days → 10 days off), with booking dates, holidays used and factor. Includes a markdown table and the page URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoPlanning year, 2025 to 2030; defaults to the year people currently plan for
localeNoLanguage of names and explanations (German only)de
regionYesRegion as name, slug or ISO code, e.g. "Bayern", "bavaria", "DE-BY", "Tirol", "Zürich" or a country like "Deutschland" / "AT". Germany, Austria and Switzerland only.

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the return payload (markdown table, page URL, booking dates, holidays used, factor) and scope (six best, non-overlapping), but says nothing about permissions, rate limits, caching, or why the list is capped at six. Read-only intent is only implied.

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

Conciseness4/5

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

A single dense sentence that front-loads the core result and then the output contents. No filler, though the parenthetical examples make it slightly long.

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?

With no output schema and only three well-documented parameters, the description usefully compensates by describing the returned fields (booking dates, holidays used, factor, markdown table, URL). Enough for an agent to call correctly, though boundary behavior (invalid region, out-of-range year) is unaddressed.

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 100%, so the schema already documents year, locale and region with examples and defaults. The description only gestures at 'of a year for a region' and adds no syntax or format detail beyond the schema; baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource: it returns the six best non-overlapping vacation levers for a region, with defined types (classic bridge days, holiday clusters). It is clear what the tool produces, though it never names or contrasts with siblings such as plan_vacation or public_and_school_holidays.

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

Usage Guidelines3/5

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

Usage is implied by the content (planning vacation around bridge days), but there is no explicit statement of when to choose this over plan_vacation or public_and_school_holidays, and no prerequisites or exclusions. The agent must infer the selection context.

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

childcare_gapSchool-holiday childcare gapBInspect

How much of a region's school holidays two vacation accounts cover, and which weeks stay open. School holidays run to about 60 working days a year while a vacation account holds 25 to 30 days, so a care day always costs exactly one vacation day and a joint family holiday costs two and covers one. Answers "can we cover the school holidays" for parents.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoPlanning year, 2025 to 2030; defaults to the year people currently plan for
localeNoLanguage of names and explanations (German only)de
regionYesRegion as name, slug or ISO code, e.g. "Bayern", "bavaria", "DE-BY", "Tirol", "Zürich" or a country like "Deutschland" / "AT". Germany, Austria and Switzerland only.
jointDaysNoCare days the family wants to spend together; they cost both parents a day and cover one. Default 10.
vacationDaysNoVacation days of the first parent; defaults to 30 in Germany, 25 in Austria and Switzerland
partnerVacationDaysNoVacation days of the second parent; omit to ask for one person alone

TDQS

B3.4/5.0
Behavior3/5

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. It does disclose a genuinely useful domain model (a care day costs exactly one vacation day; a joint family holiday costs two and covers one; roughly 60 working days vs 25-30 days of account), which is real context beyond the schema. It stops short of describing permissions, error conditions, or the shape of the result.

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

Conciseness4/5

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

Three sentences, front-loaded with the core computation before the supporting arithmetic. Each sentence contributes: purpose, cost model, and the target user's question. Slightly dense but no wasted filler.

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

Completeness3/5

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

With six parameters, no output schema, and no annotations, the description should do more. It hints at the return ('which weeks stay open') but never explains the result structure, units, or how coverage is reported, leaving an agent guessing about the response format.

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 100%, so the schema already documents all six parameters, including the jointDays costing rule. The description restates the same arithmetic model rather than adding syntax, defaults, or edge-case meaning beyond what the schema provides, so the baseline of 3 applies.

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

Purpose4/5

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

The description gives a specific verb+resource: it computes how much of a region's school holidays two vacation accounts cover, and which weeks remain uncovered. That is concrete enough for an agent to know what comes back. It does not name or differentiate itself from siblings like plan_vacation or public_and_school_holidays, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the framing question 'can we cover the school holidays' for parents, which signals the planning scenario. However, there is no explicit when-to-use versus when-not, and no routing to alternatives such as best_bridge_days or plan_vacation. Adequate but with clear gaps.

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

list_regionsList supported countries and regionsAInspect

Countries and their regions (German states, Austrian states, Swiss cantons, …) with codes, names and slugs accepted by the other tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

There are no annotations, so the description carries the full burden. It does not explicitly state that the tool is read-only or has no side effects, though the nature of a reference list implies safety. This lack of explicit transparency prevents a higher score.

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

Conciseness5/5

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

The description is a single, compact sentence that conveys all essential information without any redundancy or filler.

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?

With no output schema, the description must explain the return content. It lists the key fields (codes, names, slugs) and scope (countries and regions), which is adequate for a simple listing tool. It does not specify the exact structure (e.g., array of objects), but this is not critical for basic usage.

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

Parameters4/5

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

The tool has zero parameters, so the baseline of 4 applies. The description clearly explains what data is returned (countries, regions, codes, names, slugs), which covers the expected output without needing parameter documentation.

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

Purpose4/5

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

The title clearly states 'List supported countries and regions', but the description itself is a noun phrase rather than an explicit verb phrase. Still, it conveys the purpose of enumerating reference data and is distinct from sibling tools.

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?

The phrase 'accepted by the other tools' implies that this tool provides valid values for use in other tools, giving clear context for when to invoke it. It does not explicitly state when not to use it, but the references to sibling tools provide sufficient guidance.

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

plan_vacationPlan vacation daysAInspect

Optimal vacation plan for a region and year: which days to book so that public holidays and weekends turn into the longest breaks. Returns the plan blocks (booking dates, days off, factor, holidays used), further opportunities, a markdown table and a link to the interactive plan on urlaub-smart.de. Cite the URL when answering.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoPlanning year, 2025 to 2030; defaults to the year people currently plan for
shiftNoRolling shift rotation instead of Mon–Fri, e.g. 4 days on / 2 days off. Replaces the weekday assumption entirely.
localeNoLanguage of names and explanations (German only)de
regionYesRegion as name, slug or ISO code, e.g. "Bayern", "bavaria", "DE-BY", "Tirol", "Zürich" or a country like "Deutschland" / "AT". Germany, Austria and Switzerland only.
strategyNobalanced = mix, long-weekends = max 2 vacation days per block, extended = blocks of 4+ daysbalanced
fixedDatesNoISO dates already booked as vacation; the plan works around them
vacationDaysNoVacation days available for the year; defaults to the usual account of the country: 30 in Germany, 25 in Austria and Switzerland
carryoverDaysNoPart of vacationDays that is carry-over from last year and expires on March 31; spent first on periods before the deadline
closuresOnTopNoSet true only if the employer gives the closures on top of the vacation days; then they are treated like public holidays
schoolHolidaysNoany = ignore, avoid = no overlap with school holidays, prefer = book only inside school holidaysany
companyClosuresNoCompany closures (Betriebsferien) as inclusive ISO date ranges. By default their working days come off vacationDays, as Betriebsferien are normally scheduled annual leave
companyFreeDatesNoWorking days the employer gives off without a vacation day, ISO dates (e.g. 2027-12-24, 2027-12-31); treated like public holidays

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does a good job disclosing the return payload (plan blocks with booking dates, days off, factor, holidays used, further opportunities, markdown table, interactive link). It also gives a behavioral directive ('Cite the URL when answering'). It stops short of explaining computation caveats or limitations, but this is strong for a stateless planner.

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

Conciseness4/5

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

Two tight sentences front-load the purpose and then enumerate the return shape; the citation instruction earns its place as the last sentence. Slightly dense in the output list but 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?

With 12 parameters, no output schema, and no annotations, the description does the heavy lifting by describing the return value and citation behavior. It is largely complete for calling the tool, though it leaves sibling routing and the many planning knobs (shift, strategy, closures) entirely to the schema.

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 100%, so the schema already documents all 12 parameters in detail (region, shift, strategy, carryoverDays, etc.). The description only echoes 'region and year' and adds no syntax or semantic detail beyond the schema, so baseline 3 applies.

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 ('plan') and resource ('vacation days') plus the exact goal: turning public holidays and weekends into the longest breaks. This is clearly distinguishable from siblings like best_bridge_days or public_and_school_holidays.

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

Usage Guidelines3/5

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

The description implies when to use it (when a user wants an optimal booking plan for a region/year), but never states when NOT to use it or names an alternative such as best_bridge_days or list_regions. Usage is inferred rather than guided.

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

public_and_school_holidaysPublic and school holidaysAInspect

All public holidays (with weekday, national/regional scope, weekend flag) and school holiday periods for a region and year. Source: OpenHolidaysAPI.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoPlanning year, 2025 to 2030; defaults to the year people currently plan for
localeNoLanguage of names and explanations (German only)de
regionYesRegion as name, slug or ISO code, e.g. "Bayern", "bavaria", "DE-BY", "Tirol", "Zürich" or a country like "Deutschland" / "AT". Germany, Austria and Switzerland only.

TDQS

A3.5/5.0
Behavior3/5

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. It discloses the data source (OpenHolidaysAPI) and the shape of what is returned, which is useful, but says nothing about coverage limits beyond the schema, error behavior, caching, or rate limits an agent might hit. Adequate but with clear gaps for a no-annotation tool.

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

Conciseness4/5

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

A single front-loaded sentence covering both data types and the attribute detail, followed by a short source attribution. No filler, though the source line is of marginal operational value.

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?

With no output schema, the description steps in to sketch the returned fields (weekday, national/regional scope, weekend flag), which is what an agent needs to know the return shape. It is nearly complete for a read-only reference lookup; only the sibling relationships and any usage constraints are absent.

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 100%, so the schema already fully documents region, year and locale, including accepted region formats and locale restrictions. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

Purpose4/5

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

The description names the specific resources returned — public holidays (with weekday, national/regional scope, weekend flag) and school holiday periods — scoped to a region and year. That is far more specific than a restatement of the name, though it never explicitly contrasts itself with siblings like best_bridge_days or childcare_gap that also deal with holiday calendars.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is the reference lookup for holiday dates, but the description gives no explicit when-to-use or when-not-to-use framing, and does not say how it relates to siblings such as best_bridge_days (which presumably consumes this data) or list_regions (for valid region values).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedbest_bridge_days3 fields changed
      • changedInput schema / properties / year / description
        Previous value: -"Planning year; defaults to the year people currently plan for"New value: +"Planning year, 2025 to 2030; defaults to the year people currently plan for"
      • changedInput schema / properties / year / maximum
        Previous value: -2035New value: +9007199254740991
      • changedInput schema / properties / year / minimum
        Previous value: -2020New value: +-9007199254740991
    • Changedchildcare_gap3 fields changed
      • changedInput schema / properties / year / description
        Previous value: -"Planning year; defaults to the year people currently plan for"New value: +"Planning year, 2025 to 2030; defaults to the year people currently plan for"
      • changedInput schema / properties / year / maximum
        Previous value: -2035New value: +9007199254740991
      • changedInput schema / properties / year / minimum
        Previous value: -2020New value: +-9007199254740991
    • Changedplan_vacation3 fields changed
      • changedInput schema / properties / year / description
        Previous value: -"Planning year; defaults to the year people currently plan for"New value: +"Planning year, 2025 to 2030; defaults to the year people currently plan for"
      • changedInput schema / properties / year / maximum
        Previous value: -2035New value: +9007199254740991
      • changedInput schema / properties / year / minimum
        Previous value: -2020New value: +-9007199254740991
    • Changedpublic_and_school_holidays3 fields changed
      • changedInput schema / properties / year / description
        Previous value: -"Planning year; defaults to the year people currently plan for"New value: +"Planning year, 2025 to 2030; defaults to the year people currently plan for"
      • changedInput schema / properties / year / maximum
        Previous value: -2035New value: +9007199254740991
      • changedInput schema / properties / year / minimum
        Previous value: -2020New value: +-9007199254740991
  2. 1 tool update
    • Changedplan_vacation2 fields changed
      • addedInput schema / properties / closuresOnTop
        Added value: +{
+  "description": "Set true only if the employer gives the closures on top of the vacation days; then they are treated like public holidays",
+  "type": "boolean"
+}
      • changedInput schema / properties / companyClosures / description
        Previous value: -"Company closures (Betriebsferien) as inclusive ISO date ranges; treated like public holidays"New value: +"Company closures (Betriebsferien) as inclusive ISO date ranges. By default their working days come off vacationDays, as Betriebsferien are normally scheduled annual leave"
  3. 2 tool updates
    • Changedchildcare_gap2 fields changed
      • removedInput schema / properties / vacationDays / default
        Removed value: -30
      • changedInput schema / properties / vacationDays / description
        Previous value: -"Vacation days of the first parent"New value: +"Vacation days of the first parent; defaults to 30 in Germany, 25 in Austria and Switzerland"
    • Changedplan_vacation2 fields changed
      • removedInput schema / properties / vacationDays / default
        Removed value: -30
      • changedInput schema / properties / vacationDays / description
        Previous value: -"Vacation days available for the year"New value: +"Vacation days available for the year; defaults to the usual account of the country: 30 in Germany, 25 in Austria and Switzerland"
  4. 4 tool updates
    • Changedbest_bridge_days1 field changed
      • addedInput schema / properties / region / maxLength
        Added value: +80
    • Changedchildcare_gap1 field changed
      • addedInput schema / properties / region / maxLength
        Added value: +80
    • Changedplan_vacation9 fields changed
      • addedInput schema / properties / companyClosures / items / properties / from / maxLength
        Added value: +10
      • addedInput schema / properties / companyClosures / items / properties / to / maxLength
        Added value: +10
      • addedInput schema / properties / companyClosures / maxItems
        Added value: +12
      • addedInput schema / properties / companyFreeDates / items / maxLength
        Added value: +10
      • addedInput schema / properties / companyFreeDates / maxItems
        Added value: +60
      • addedInput schema / properties / fixedDates / items / maxLength
        Added value: +10
      • addedInput schema / properties / fixedDates / maxItems
        Added value: +60
      • addedInput schema / properties / region / maxLength
        Added value: +80
      • addedInput schema / properties / shift / properties / firstWorkingDay / maxLength
        Added value: +10
    • Changedpublic_and_school_holidays1 field changed
      • addedInput schema / properties / region / maxLength
        Added value: +80
  5. 4 tool updates
    • Changedbest_bridge_days1 field changed
      • changedInput schema / properties / region / description
        Previous value: -"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\""New value: +"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\". Germany, Austria and Switzerland only."
    • Changedchildcare_gap1 field changed
      • changedInput schema / properties / region / description
        Previous value: -"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\""New value: +"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\". Germany, Austria and Switzerland only."
    • Changedplan_vacation1 field changed
      • changedInput schema / properties / region / description
        Previous value: -"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\""New value: +"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\". Germany, Austria and Switzerland only."
    • Changedpublic_and_school_holidays1 field changed
      • changedInput schema / properties / region / description
        Previous value: -"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\""New value: +"Region as name, slug or ISO code, e.g. \"Bayern\", \"bavaria\", \"DE-BY\", \"Tirol\", \"Zürich\" or a country like \"Deutschland\" / \"AT\". Germany, Austria and Switzerland only."
  6. 2 tool updates
    • Addedchildcare_gap
    • Changedplan_vacation1 field changed
      • addedInput schema / properties / shift
        Added value: +{
+  "description": "Rolling shift rotation instead of Mon–Fri, e.g. 4 days on / 2 days off. Replaces the weekday assumption entirely.",
+  "properties": {
+    "firstWorkingDay": {
+      "description": "ISO date of the first working day of a cycle",
+      "type": "string"
+    },
+    "offDays": {
+      "maximum": 14,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "onDays": {
+      "maximum": 14,
+      "minimum": 1,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "onDays",
+    "offDays",
+    "firstWorkingDay"
+  ],
+  "type": "object"
+}
  7. 3 tool updates
    • Changedbest_bridge_days1 field changed
      • changedInput schema / properties / locale / description
        Previous value: -"Language of names and explanations"New value: +"Language of names and explanations (German only)"
    • Changedplan_vacation1 field changed
      • changedInput schema / properties / locale / description
        Previous value: -"Language of names and explanations"New value: +"Language of names and explanations (German only)"
    • Changedpublic_and_school_holidays1 field changed
      • changedInput schema / properties / locale / description
        Previous value: -"Language of names and explanations"New value: +"Language of names and explanations (German only)"
  8. 4 tool updates
    • First observedbest_bridge_days
    • First observedlist_regions
    • First observedplan_vacation
    • First observedpublic_and_school_holidays

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources