Date Math

Visa stay calculator (Schengen 90/180)

stay_calculator

Read-onlyIdempotent

Rolling stay-limit math such as the Schengen 90/180 rule: days used in the window, days left, overstay check, the longest stay allowed from a planned entry date, and the next date a full stay is possible. Entry and exit days both count. Custom rules via max_days/window_days. Use for travel planning, visa-free stays and "can I enter on". First 25 calls per day are free, then $0.001 per call (x402).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trips": "<trips>"
    },
    "name": "stay_calculator"
  }
}

Input Schema

Name	Required	Description
`date`	No
`entry`	No
`trips`	Yes	Past and planned stays. Entry and exit days both count as days present.
`max_days`	No
`window_days`	No	Length of the rolling window, counted back from each day (inclusive)

Output Schema

Name	Required	Description
`date`	Yes
`note`	Yes
`rule`	Yes
`max_stay`	Yes	Present when entry was given
`days_used`	Yes	Days present in the window ending on date
`in_compliance`	Yes
`overstay_days`	Yes
`days_remaining`	Yes
`first_overstay`	Yes	First day any trip broke the rule, or null
`next_full_stay_date`	Yes	Earliest date after date from which a full max_days stay is allowed

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the description is not burdened with safety disclosure and instead adds cost behavior: 25 free calls per day then $0.001 per call via x402. It also discloses the counting convention ('Entry and exit days both count'), which materially affects results. It stops short of explaining error behavior for malformed or overlapping trips.

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?

Front-loaded with the core purpose and the enumerated result types before the pricing tail; every clause carries information. The sentence is long and dense, packing purpose, outputs, counting rule, overrides, use cases, and pricing into one block, but nothing is redundant.

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?

An output schema exists, so the description need not document return values, and the annotation set covers the safety profile. What remains is the unresolved distinction between the top-level 'date' and 'entry' inputs, which is the one gap an agent could trip over when calling it.

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 only 40%, and the description compensates partially: it explains max_days/window_days as custom rule overrides and confirms inclusive day counting for trips. However, the top-level 'date' and 'entry' parameters have no schema description and no mention in the description, leaving their roles (reference date vs. planned entry) to inference.

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?

The description names the specific computation (rolling stay-limit math, Schengen 90/180) and enumerates the concrete outputs: days used, days left, overstay check, longest stay from a planned entry, and next possible full-stay date. That is enough for an agent to separate it from generic date arithmetic siblings like date_diff or date_add.

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?

It gives positive usage context ('travel planning, visa-free stays', 'can I enter on') which maps cleanly onto the decision an agent faces. It does not name an alternative or state when not to use it, so it falls short of a full 5, but the intended scenario is unambiguous.

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

All Date Math tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.