Skip to main content
Glama

工作日天数统计

workday_count

Count workdays and rest days between two inclusive dates, accounting for Chinese statutory holidays and adjusted workdays.

Instructions

统计两个日期之间(含首尾)的工作日与休息日天数,已考虑节假日与调休

Input Schema

NameRequiredDescriptionDefault
endYes日期,格式 YYYY-MM-DD
startYes日期,格式 YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description must carry the behavioral burden. It usefully discloses that holidays and 调休 (adjusted workdays) are factored in, which is real behavioral information beyond the schema. However, it doesn't state which region's holiday calendar applies, what data range is covered, or anything about the response shape.

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

Conciseness5/5

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

A single compact sentence with no filler, and the key behavioral fact (holiday/调休 awareness) is front-loaded alongside the core verb. Nothing repeats the title or wastes space.

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?

For a simple two-date read-only counting tool with a fully documented schema and no output schema, the description covers inclusive range, both counts returned, and holiday logic. The main remaining gap is calendar scope — which country/year holiday data is applied — which matters given the 调休 reference.

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 description coverage is 100%, so the baseline is 3. The description earns an extra point by clarifying that both endpoints are inclusive (含首尾), a semantic detail the schema does not express and one that directly affects how an agent sets start and end.

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?

States a specific verb+resource: count working days and rest days between two dates, inclusive. This is clearly distinct from siblings like workday_add (which shifts a date) and holiday_check (which inspects a single date), though no sibling is named explicitly. Purpose is unambiguous without opening the schema.

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

Usage Guidelines3/5

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

Usage is only implied by the description's scope — you call it when you need a range-level count. There is no explicit 'use this when…' statement, no mention of workday_add or holiday_check as alternatives, and no preconditions such as supported year ranges.

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