Calcgrid

Count Peru Working Days

count_pe_working_days

Read-onlyIdempotent

Use this when you need an auditable Peru working-day count. Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery.

Do not use this when choose calendar_scope and workweek explicitly. National holidays and public-sector compensable days have different applicability. This is a declared five-day (Saturday-Sunday rest) or six-day (Sunday rest) planning calendar, not proof of an individual's roster. Essential services, private-employer adoption, compensating shifts, regional holidays, banking, school, tax and procedural deadline calendars require separate evidence. The two compensable public-sector days remain working days for tax purposes. Later decrees require a new snapshot; dates beyond 2026 are unsupported. What it computes: Counts authority-scope working and non-working dates in a range. Required calendar_scope and workweek distinguish national holidays from compensable public-sector days and five/six-day rosters. Example user requests: Peru: National July week. | Peru: Public-sector July week. Inputs: start_date (date); end_date (date); include_start_date (boolean, optional); include_end_date (boolean, optional); calendar_scope (enum); workweek (integer). Complete JSON argument examples: {"start_date":"2026-07-24","end_date":"2026-07-30","calendar_scope":"national_statutory","workweek":5} | {"start_date":"2026-07-24","end_date":"2026-07-30","calendar_scope":"public_sector","workweek":5} Outputs: working_days, non_working_days, public_holidays_counted, territory, territory_name, day_type, holiday_names, holiday_kinds, holiday_details, calendar_scope, holiday_policy, substitute_day_policy, calendar_profile, dataset_version, sources, calendar_selection, workweek, compensable_day_details. Formula: working day = outside selected weekly rest and selected holiday layer Direct REST fallback: POST https://tttkmbb.com/api/v1/calculate/peru-public-working-days-between with the same JSON input fields. Do not guess another /api/* path. Docs: https://tttkmbb.com/everyday/peru-public-working-days-between.md

Input Schema

TableJSON Schema

Name	Required	Description
`end_date`	Yes	Last date in 2026-2026.
`workweek`	Yes	Required declared baseline: 5 = Saturday-Sunday rest, 6 = Sunday rest. Confirm the applicable roster.
`start_date`	Yes	First date in 2026-2026.
`calendar_scope`	Yes	Required: national_statutory uses 16 national holidays; public_sector also applies the two published compensable days. Neither is a tax or individual employee roster.
`include_end_date`	No	Whether end_date participates.
`include_start_date`	No	Whether start_date participates.

Output Schema

TableJSON Schema

Name	Required	Description
`links`	No
`result`	Yes
`request`	Yes
`sources`	No
`success`	Yes
`version`	No
`freshness`	No
`timestamp`	Yes
`next_actions`	No
`service_version`	Yes	Deployed Calcgrid implementation version used for the result.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 29, 2026

TDQS

A3.6/5.0

Behavior5/5

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

The description adds substantial context beyond annotations: it discloses that the calendar is a declared planning calendar, not proof of an individual's roster, lists excluded domains (essential services, banking, tax deadlines, etc.), notes data limits ('dates beyond 2026 are unsupported'), and states that later decrees require a new snapshot. This goes well beyond the readOnly/idempotent annotations.

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

Conciseness3/5

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

The description is long and includes redundant output listings, formula, REST fallback, and docs, despite having an output schema. It is front-loaded with usage guidance, but several sentences (especially the garbled 'Do not use' clause) do not earn their place.

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?

Given the output schema and rich annotations, the description is nearly complete: it covers scope, limitations, data version, unsupported dates, and usage directives. The only notable gap is the unclear routing guidance, but overall an agent has enough context to invoke the tool correctly.

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 baseline is 3. The description reiterates the role of calendar_scope and workweek and gives examples, but the schema already documents both parameters in detail, so the added meaning is marginal.

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 ('Counts authority-scope working and non-working dates in a range') and gives example requests. It implies a distinction from single-day checkers via 'in a range' but does not explicitly name sibling tools like check_pe_working_day or add_pe_working_days, so sibling differentiation is not fully explicit.

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

Usage Guidelines2/5

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

It offers a 'use this when' condition (auditable Peru working-day count) but the negative guidance is garbled ('Do not use this when choose calendar_scope and workweek explicitly') and no alternative tool is named. The agent cannot reliably route between this and check_pe_working_day or add_pe_working_days from the text.

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

All Calcgrid tools Inspect

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

Need Help?