calc_payday_super_deadline

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly discloses important limitations: the tool does not invent clearing-house latency, cannot confirm LCR 2026/1 transition allocation, and cannot return ON_TIME without a fund-receipt date. This is far more transparent than a typical description, though it does not address side effects or authentication.

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?

The description is compact and information-dense; each sentence contributes either a parameter definition, a format rule, or a limitation. The main purpose is stated clearly in the first sentence. The ordering could be slightly improved, but there is no padding.

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?

For a domain-specific tool with 10 parameters and no annotations, the description covers required inputs and key behavioral caveats but leaves most optional flags opaque. An agent would need significant outside domain knowledge to correctly set db_interest, out_of_cycle, first_to_fund, next_standard_qe_day, or employee_id. The output schema exists, but the input side is incomplete.

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 description coverage is 0%, so the description must compensate by explaining parameters. It explains qe_day, as_at, received, and remitted, and notes ISO-8601 dates and decimal strings, but 6 of 10 parameters, including sg_amount, db_interest, out_of_cycle, first_to_fund, next_standard_qe_day, and employee_id, remain effectively unexplained or only given by their schema titles.

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 has a specific verb and resource: 'Review one contribution against payday-super-checker,' which aligns with the tool name and the statutory/ON_TIME language. It is distinguishable from the unrelated sibling tools. However, 'payday-super-checker' itself is not elaborated, so a non-domain agent is left inferring the exact computation.

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?

The intended use is implied: assess a contribution against the payday-super deadline. It provides useful input guidance such as as_at being required and received/remitted semantics, but it does not explicitly say when to choose this tool over an alternative or when not to use it.

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