Summarize my working hours

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

Beyond the readOnly/openWorld annotations, it discloses that the overtime figure is an ESTIMATE (a correctness caveat the agent must relay), that results are scoped to the caller's own data, that output is broken down per month, and that the range is capped at 366 days. Auth requirements and empty-result behavior remain unstated.

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

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

A single dense sentence front-loads the purpose and enumerates outputs, followed by a short defaults/limits clause and the estimate disclaimer. The bilingual parenthetical glosses add length but serve the Japanese-domain audience; nothing is redundant with the schema.

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

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

With only two optional parameters, no output schema, and annotations already covering the safety profile, the description is fully sufficient: it names every returned metric, the per-month structure, the default window, the maximum range, and the mandatory caveat about the overtime estimate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 that by adding a constraint not in the schema — the 366-day maximum span — and by reiterating the default range meaningfully against the 'summarize over a period' purpose. It adds no format hints beyond what the YYYY-MM-DD patterns already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Summarize') on a specific resource ('your own working hours') and enumerates the exact aggregates returned: total actual working time, work days, holiday work days, overtime estimate, and per-month breakdown. The 'your own' scope implicitly separates it from team-level siblings like get_manhours or list_projects, but no sibling is named explicitly.

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

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

It gives concrete operating context: defaults to the 1st of this month through today and caps the span at 366 days, plus an instruction to always disclose that overtime is an estimate. It never states when to prefer this over get_working_records or get_manhours (raw records vs aggregated summary), so no exclusion guidance is present.

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