Calcgrid

Count Bulgaria Working Days

count_bg_working_days

Read-onlyIdempotent

Use this when you need an auditable Bulgaria 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 bulgaria 2026 nationwide statutory holidays, observed non-attendance days and January 2 one-off rest over an explicitly selected Monday-Friday planning baseline. November 1 is education-only and does not add general rest. No personal, shift, school, employer, bank/exchange, optional religious-leave, payroll or legal-deadline schedule is computed. Future years and additional local/sector closures are unsupported. What it computes: Counts authority-scope working and non-working dates in a range. Requires explicit mon_fri_planning; education-only holidays do not create general rest. Example user requests: Count Bulgaria working days around One-off euro transition rest, not statutory holiday. | Count Bulgaria working days around May 24 Sunday replacement. | Count Bulgaria working days around No nationwide school-holiday substitute. Inputs: start_date (date); end_date (date); include_start_date (boolean, optional); include_end_date (boolean, optional); work_schedule (enum). Complete JSON argument examples: {"start_date":"2026-04-09","end_date":"2026-04-14","work_schedule":"mon_fri_planning"} 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, work_schedule, is_statutory_holiday, is_observed_non_attendance_day, is_one_off_non_attendance_day, is_education_only_holiday, observed_for_dates, payroll_scope. Formula: planning_workday = weekday AND no nationwide statutory/observed/one-off rest event Direct REST fallback: POST https://tttkmbb.com/api/v1/calculate/bulgaria-public-working-days-between with the same JSON input fields. Do not guess another /api/* path. Docs: https://tttkmbb.com/everyday/bulgaria-public-working-days-between.md

Input Schema

TableJSON Schema

Name	Required	Description
`end_date`	Yes	Last date in 2026-2026.
`start_date`	Yes	First date in 2026-2026.
`work_schedule`	Yes	Required explicit Monday-Friday planning baseline, not a universal legal 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

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds valuable domain-specific details: it requires an explicit Monday-Friday planning baseline, explains that education-only holidays do not create general rest, and lists what is not computed (payroll, legal deadlines, etc.).

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 repetitive, including a garbled sentence, multiple example user requests, and a full output list that duplicates the output schema. It is front-loaded with purpose and usage, but several sections could be trimmed without losing 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?

Given the tool's complexity, the description is complete: it covers inputs, outputs, formula, REST fallback, and documentation link. It includes more than necessary in some areas, but nothing critical is missing for an agent to call it 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 schema already documents all parameters. The description restates the inputs and provides a JSON example, but adds little meaning beyond what the schema already conveys, apart from reinforcing the work_schedule requirement.

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 states a specific verb (count) and resource (Bulgaria working days), and explicitly scopes the tool to Bulgaria, distinguishing it from the many country-specific siblings. It also clarifies that it is an 'auditable' count, setting expectations for the result.

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 provides clear when-to-use guidance ('Use this when you need an auditable Bulgaria working-day count') and lists exclusions such as no personal/shift/school schedules and unsupported future years. However, the 'Do not use this when' clause is garbled and does not name alternative tools, leaving some ambiguity.

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?