Skip to main content
Glama
Sign In

PlugRail Japanese Calendar

by dev.plugrail
OverviewDiscussionsAdmin

add_business_days

Read-onlyIdempotent

指定した日付(date)の翌日から数えてN営業日目(days)の日付を返します。dateの当日は数えません。daysが負の場合は過去方向（dateの前日から遡ってN営業日目）に計算します。土日・日本の祝日を除外し、calendar="banking"を指定すると銀行休業日（12/31〜1/3）も除外します。dateが営業日かどうかだけ知りたい場合は is_holiday を使ってください（days=0でも同じ情報がskipped経由で得られます）。入力例: {"date": "2026-07-10", "days": 3}

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": {
      "date": "<date>",
      "days": "<days>"
    },
    "name": "add_business_days"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYes起点日 YYYY-MM-DD。例: "2026-07-10"。この日自体は数えません。
daysYes何営業日先(正)/前(負)かを表す整数。0も指定可: dateをそのまま返し、dateが非営業日ならskippedに1件（date自身とその理由）を記録します。
calendarNo"standard"（既定）または"banking"（銀行休業日も除外）。
extra_closed_datesNo顧客固有の追加休業日（YYYY-MM-DD の配列）。例: ["2026-12-29", "2026-12-30"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • changedInput schema / properties / days / description
      Previous value: -"何営業日先(正)/前(負)かを表す整数。0は不可（is_holidayまたはdays=1を使用）。"New value: +"何営業日先(正)/前(負)かを表す整数。0も指定可: dateをそのまま返し、dateが非営業日ならskippedに1件（date自身とその理由）を記録します。"
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real substance: weekends and Japanese holidays are excluded, `calendar="banking"` additionally excludes 12/31–1/3, the start day is not counted, and negative values traverse backwards. It stops short of describing the response shape (e.g. the `skipped` array is only alluded to in passing).

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 verb and counting rule, then constraints, then the alternative — a sensible order with no filler. Slightly redundant in restating the is_holiday/skipped relationship twice, and the trailing JSON input example adds little given the schema already has examples.

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?

There is no output schema, and the description only loosely sketches the return value (a date, plus a `skipped` record when relevant), so the response shape remains partly implicit. Everything an agent needs to compute and call correctly — counting rules, calendar modes, sign handling — is present.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above-baseline credit by clarifying the off-by-one counting convention and by noting that days=0 still surfaces non-business-day information via `skipped`. It does not mention `extra_closed_dates` at all, which holds it back from a 5.

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 (returns the date N business days from `date`) plus the exact counting start point, and explicitly names `is_holiday` as the different sibling for a different question. An agent can select this over `business_days_between`/`is_holiday` without opening another schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use routing: 'if you only need to know whether date is a business day, use is_holiday' — and even explains the days=0 workaround. Also defines behavior for negative days and for the calendar option, leaving no selection ambiguity.

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

All PlugRail Japanese Calendar toolsInspect
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