Tanod MCP server

utilpeek: count business days or add working days (with public holidays)

count_or_add_business_days

Read-onlyIdempotent

Count business days between two dates or add working days, skipping weekends and country-specific public holidays.

Instructions

utilpeek: Count business days between two dates or add working days, skipping public holidays. For the holiday list use get_public_holidays. Returns the business days between two dates (mode count; both ends included by default, like NETWORKDAYS) or the date N business days after or before a date (mode add, like WORKDAY), skipping weekends (configurable) and, with a country, its public holidays; plus the holidays skipped. Input: mode, start, for count end and optional include_start / include_end, for add days, optional weekend, country and subdivision. Ranges up to 20 years; with a country, dates in 1990-2100. Bad input is a 422 (not charged). Holiday rules are modelled by a library: confirm with an official source for legal or payroll use. Typically under 0.2 s. Price: USD 0.001. Free: 10 utilpeek calls per IP per UTC day. Docs: https://tanod.dev/learn/business-days-api.html

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	count only: end date, YYYY-MM-DD, at most 20 years from start (before start gives a negative count).
`days`	No	add only: business days to add (negative subtracts). The start date is never counted (like Excel WORKDAY); 0 returns start.
`mode`	Yes	count: business days between start and end; add: the date `days` business days after (or before) start.
`start`	Yes	Start date, YYYY-MM-DD (1900-01-01..2199-12-31).
`country`	No	Optional ISO 3166-1 alpha-2 country whose public holidays are not business days (the /v1/holidays data; dates in 1990-2100).
`weekend`	No	Weekday names that are not business days (default ["sat", "sun"]; e.g. ["fri", "sat"]; [] for none).
`include_end`	No	count only: count the end date (default true; both true is Excel NETWORKDAYS, include_end false the half-open [start, end) of numpy.busday_count).
`subdivision`	No	Optional subdivision code or name for that country (e.g. CA or California for US).
`include_start`	No	count only: count the start date (default true).

Output Schema

TableJSON Schema

Name	Required	Description
`end`	No
`date`	No
`days`	No
`mode`	No
`note`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`start`	No
`source`	No
`country`	No
`weekday`	No
`weekend`	No
`counting`	No
`include_end`	No
`subdivision`	No
`holiday_days`	No
`weekend_days`	No
`business_days`	No
`calendar_days`	No
`include_start`	No
`holidays_skipped`	No
`holidays_truncated`	No
`start_is_business_day`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (which only cover read-only/idempotent safety) by disclosing bad-input behavior (422, not charged), latency (<0.2 s), price and the 10-free-calls-per-IP-per-UTC-day quota, and an accuracy caveat that holiday rules are library-modelled and should be confirmed with an official source for legal/payroll use.

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?

Purpose and the mode split are front-loaded, and most information earns its place. It is dense and includes some boilerplate (pricing, docs URL) and re-explains return values the output schema already carries, so it is not maximally tight.

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

Completeness5/5

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

With an output schema present and 100% parameter coverage, the description only needs to frame behavior, and it does: both modes, inclusion semantics, supported date ranges (20 years; 1990-2100 with a country), error code, cost, and a legal caveat.

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 already 100%, so baseline is 3, but the description adds value by grouping which parameters apply to which mode (end/include_start/include_end for count; days/weekend/country/subdivision for add) and flags that weekends are configurable and a country adds its public holidays.

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 two specific operations with verb+resource: count business days between two dates, or add working days. It distinguishes itself from the sibling get_public_holidays by naming it and explaining the relationship (this tool uses the holiday data, that tool lists it).

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?

Explains when to use each mode (count vs add) with the Excel NETWORKDAYS/WORKDAY analogies and routes to get_public_holidays for the holiday list. It does not compare against other date siblings (convert_time, cron_next_runs, expand_rrule), so the routing is clear but not exhaustive.

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

Deploy Server