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

Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate safety. It adds valuable behavioral details: handling after-sunset events, Adar in leap years, and Cheshvan/Kislev edge cases, which are critical for correct Hebrew calendar computation. It also states the batch limit (up to 10 entries), which influences how an agent should structure calls. No contradiction with annotations is present.

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 succinct, with the core purpose in the first sentence and supplementary details in the second. It avoids redundancy and front-loads the most important information, making it easy for an agent to parse quickly. Every sentence contributes meaningful detail without unnecessary elaboration.

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 read-only computation tool, the description covers the main inputs and edge cases that are essential for correct usage. It does not explicitly state the return format, but since the purpose is to compute dates, the output (list of Gregorian dates) is inferred. The batch limit and edge-case handling are included, which are critical nuances. Missing are details about error handling or behavior when no dates are found, but these are minor given the scope. Overall, it is fairly complete for an agent to invoke it correctly.

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?

The schema already describes each parameter, but coverage is only 50% (the 'entries' property lacks a description). The description clarifies that 'date' is the original Gregorian date and specifies the batch limit (up to 10 entries), which aligns with maxItems. However, it does not explain the 'years' parameter or the meaning of 'type' beyond the enum values, leaving the agent to rely on the schema. The added context is helpful but not enough to fully compensate for the missing description of 'entries'.

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 clearly states a specific verb ('Compute') and resource ('upcoming Gregorian dates for yahrzeits, Hebrew birthdays or Hebrew anniversaries') derived from an original Gregorian date. It distinguishes the tool's function from broad calendar tools like get_jewish_calendar, though it does not explicitly name an alternative sibling. The purpose is unambiguous and informative.

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 description provides no guidance on when to use this tool versus alternatives such as convert_date or get_shabbat_times. It does not mention any exclusions or edge scenarios that would route the agent to another tool. The intended use cases are implied by the description (yahrzeits, birthdays, anniversaries) but no explicit direction is given.

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