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

No annotations exist, so the description carries full behavioral disclosure responsibility. It does add a valuable behavioral trait: 'Does NOT assume Saturday/Sunday weekend globally.' However, it does not disclose return value formats, operation-specific parameter expectations, or edge-case behavior such as invalid dates or ambiguous holiday definitions.

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?

Three compact sentences with no filler. The core purpose is front-loaded, and each subsequent sentence adds relevant context: operation list, country/holiday support, and the weekend assumption clarification.

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 8 parameters, 7 operations, no output schema, and no annotations, the description is under-specified. It does not explain which parameters each operation requires (e.g., count requires start_date and end_date), nor does it describe return types. This leaves substantial room for incorrect invocation.

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 100%, so the baseline is 3. The description adds some semantic grouping by pairing operations with implied parameters (e.g., 'add business days' implies date+count, 'count business days between dates' implies start_date/end_date), but it doesn't go beyond that to clarify conditional requirements per operation.

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 enumerates the specific operations (is_business_day, next, previous, add, count, last_of_month, range) and clearly frames the tool as business-day calculations. It distinguishes itself from sibling tools like holidays and calculate_date by focusing specifically on business-day logic and even notes the global weekend assumption.

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 implies usage for business-day calculations and mentions country-specific holidays/weekends, but it never explicitly says when to prefer this tool over siblings like holidays or calculate_date, nor when not to use it. No exclusion or boundary statements are provided.

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

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

With no annotations present, the description carries the burden of behavioral disclosure. It adds useful context by stating the tool is deterministic and correctly handles leap years and month-end edge cases. However, it does not mention return format, invalid-date handling, or timezone/calendar behavior, which are relevant for a tool with 9 parameters.

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 front-loaded with the core purpose, followed by operation categories, a correctness guarantee, and a concrete example. Every sentence earns its place with no redundant content.

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?

Given the tool's complexity (9 parameters, 5 enums, no output schema), the description covers the main arithmetic and boundary operations but omits weekday operations, alternate calendars, and timezone handling. It does not describe the return shape, but the description is adequate for core usage without being fully comprehensive.

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 78%, which is high, so the baseline of 3 applies. The example '2026-01-31 + 1 month → 2026-02-28' clarifies the month-add semantics beyond the schema, but the description omits weekday operations (next_weekday/previous_weekday) and does not explain operation-specific parameter dependencies.

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 the tool performs deterministic date arithmetic, naming specific operation categories: add/subtract, snap to boundaries, and diff. It is distinct from the sibling tools' domains (time conversion, holidays, business days), but it does not explicitly name or contrast a sibling to help with disambiguation.

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 implies usage for general date arithmetic through its opening phrase and example. However, it provides no explicit guidance on when not to use this tool or which sibling might be more appropriate (e.g., business_days for business-day logic, convert_time for timezone conversion).

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only lists operations without explaining side effects, output formats, or operation-specific behavior such as what 'events' does or what happens with invalid dates. The first-class Persian/Jalali note adds some context but not enough.

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 short, front-loaded, and free of filler. It enumerates core operations efficiently, though the 'events' operation is omitted entirely.

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?

The tool has six operations, six parameters, an enum-heavy schema, and no output schema, yet the description does not explain operation-specific parameter requirements or return behavior. An agent cannot reliably know that 'convert' needs target_calendar, that month_info needs year and month, or what 'events' expects, so the description 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 100%, so the baseline is 3. The description adds minor context about calendar systems and month-related operations, but it does not meaningfully clarify parameter combinations, defaults, or format expectations beyond the schema.

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 identifies the tool's purpose: calendar system operations including converting between calendar types, validating dates, computing weekdays, and generating month calendars. It names specific functionality and resources, though it does not explicitly differentiate itself from the overlapping sibling 'jalali_persian'.

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?

No guidance is provided on when to use this tool versus alternatives like convert_time or jalali_persian. The description never states exclusions, preferred scenarios, or when a sibling would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. It explicitly discloses DST-transition handling, date-boundary changes, and a no-hardcoded-offset policy, which are meaningful behavioral guarantees. It does not cover error or return behavior, but the key traits for a conversion tool are covered.

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?

Four focused sentences, front-loaded with the core action and followed by behavioral constraints. There is no filler, redundancy, or unnecessary detail.

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 3-parameter tool with no output schema or annotations, the description covers inputs, timezone standards, DST handling, and multi-target conversion. It leaves return format and error cases unspecified, which are minor for this operation.

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 100%, so the baseline is 3. The description reinforces datetime format and IANA names, but mostly repeats what the schema already states; it adds no genuinely new parameter semantics beyond illustrative examples.

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?

States a specific verb ('Convert') and resource ('a datetime between IANA timezones'), and the emphasis on IANA/DST/multiple targets differentiates it from siblings like format_time and timezone_info. The purpose is unambiguous and actionable.

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?

Provides clear context: instructs to use IANA names, forbids hardcoded UTC offsets, and notes multi-target support. It does not explicitly name alternatives or state when-not-to-use, but the constraints are enough to guide correct usage.

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

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

With no annotations provided, the description carries the full burden, and it does contribute the guarantee that formatting is 'deterministically' performed and lists broad format support. However, it does not disclose timezone handling, invalid-input behavior, default calendar/locale semantics, or what the returned string looks like, leaving notable behavioral gaps.

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 short and front-loaded, with the purpose in the first sentence and format capabilities in the second. The final sentence about Intl.DateTimeFormat is slightly implementation-oriented and could be removed, but overall the structure wastes little space.

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 5-parameter tool with no annotations and no output schema, the description is too thin to be fully actionable: it omits timezone semantics, output form, error behavior, and how to route between this and the related temporal siblings. An agent would likely need to inspect parameter defaults or experiment to invoke it confidently.

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?

With only 40% schema description coverage, the description partially compensates by naming locale examples (en-US, de-DE, ja-JP, fa-IR) and mentioning Jalali and custom Luxon formats. It still leaves timezone semantics essentially undocumented and adds little beyond the schema's already-detailed format and datetime property descriptions.

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 identifies the operation as 'Deterministically format a datetime string' and enumerates the supported output families (ISO 8601, RFC 3339, locale-aware, Jalali, human-readable, and custom Luxon formats), so an agent can understand the core purpose. It does not explicitly contrast it with sibling tools like convert_time or resolve_time, but 'format' as the verb is sufficiently distinct.

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?

No when-to-use versus alternatives is given; there are no exclusions or routing conditions relative to convert_time, now, resolve_time, or other siblings. The only instruction-like sentence, 'Use Intl.DateTimeFormat for locale-specific output,' appears to describe an implementation detail rather than when an agent should select this tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds two substantive disclosures: the data source ('IATA holiday database') and the actual-vs-observed date distinction, both of which shape how results should be interpreted. It does not cover rate limits or coverage caveats, but for a read-only query tool the two disclosures provide meaningful value.

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?

Three sentences with zero waste: the capability list is front-loaded in sentence one, sentence two adds data-source scale, sentence three adds result semantics. Every sentence earns its place.

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 tool with 7 parameters, 5 enum operations, no annotations, and no output schema, the description covers four of five operations but omits 'countries' entirely. It also never states which parameters each operation requires, even though only 'operation' is marked required in the schema — an agent must infer that list needs country_code, that is_holiday needs date, etc. No return-value or failure behavior is hinted at either.

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 adds value by implicitly mapping operations to parameter groups (list → country_code + year, between → country_code + start_date/end_date, is_holiday → country_code + date), which the schema's per-property descriptions do not convey. The mapping is implicit rather than explicit, and the 'countries' operation is never tied to its (empty) parameter set, preventing a 5.

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 enumerates specific verbs with a clear resource: 'list all holidays for a country and year', 'check if a specific date is a holiday', 'find the next upcoming holiday', 'get holidays in a date range'. This positions it distinctly against temporal siblings like business_days and calendar, and the IATA database mention anchors its scope.

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 four enumerated query modes give clear context for when an agent would invoke this tool. However, it never explicitly names sibling alternatives or exclusion conditions — e.g., no statement like 'for business-day arithmetic use business_days' — so routing relies on inference rather than explicit guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool is a convenience wrapper, but it does not state read-only behavior, output format, date handling rules, error cases, or any limitations. For a tool with seven operations, this is a significant transparency gap.

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?

Two tight sentences with the operation list front-loaded and the alternative routing stated immediately. No wasted words or redundant restatement of the tool name.

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?

This is a multi-operation tool with 7 parameters and no output schema, yet the description provides no return-value information, no operation-to-parameter mapping, and no date semantics. The schema's generic property descriptions are not enough for an agent to confidently determine what each operation expects or returns.

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 100%, so the schema already documents all parameters, giving a baseline of 3. The description's operation list loosely aligns with the enum values but adds no extra meaning about which parameters are required per operation or how the parameters combine.

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 states a specific resource (Persian/Jalali calendar) and enumerates distinct operations: converting dates, looking up events, getting month overviews, and calculating days until Jalali dates. It also explicitly distinguishes itself from the universal 'calendar' sibling, so an agent can tell what this tool is for.

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 clearly indicates this tool is for Jalali-specific functionality and explicitly directs universal calendar operations to the 'calendar' tool instead. However, it does not address other potentially overlapping siblings like 'holidays' or 'convert_time', leaving some edge-case routing ambiguous.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the return contents and the tool's authoritative role, but it does not cover error behavior, timezone validity, or what happens with different calendar options. The phrase 'deterministic time' is also slightly confusing given that current time changes, which undermines transparency.

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 only three sentences, with the purpose and usage rule front-loaded. Every sentence adds value: purpose, call-don't-infer rule, and return fields. There is no redundancy or filler.

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 simple tool with zero required parameters and a fully documented schema, the description provides the essential output fields and usage rule. It is slightly incomplete because it does not state output formatting or how timezone/calendar parameters affect the result, but given the low complexity, the gap is minor.

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 100%, with both parameters (calendar and timezone) already documented meaningfully in the schema. The description adds nothing about the parameters themselves, so the baseline of 3 applies.

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 the tool returns the current deterministic time and enumerates the exact output fields (UTC and local time, weekday, UTC offset, DST status). It is specific and unambiguous about the resource and verb, but it does not explicitly differentiate itself from sibling tools such as convert_time or timezone_info, so it misses the top score.

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 instruction 'Do NOT let the LLM infer the current date/time — call this tool instead' is a strong, explicit usage guideline that tells the agent when to invoke this tool. However, it does not mention alternatives or conditions for when to choose a sibling tool, so it lacks the explicit routing that would earn a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds valuable guarantees: deterministic conversion 'where possible', always bounded results, and never infinite recurrences. It does not discuss output format or invalid-input behavior, but the core safety constraints are covered.

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?

Three sentences with no filler; the main purpose is front-loaded, and the boundedness guarantee is delivered in compact separate statements. Every sentence earns its place.

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?

The description adequately covers purpose and constraints, but it does not address the relationship between the rrule and natural_language fields—for instance, what happens if both are provided or neither is provided. Since no output schema exists, this ambiguity is a real gap.

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 high (83%), so the baseline is 3. The description adds meaning by explaining that natural_language inputs are deterministically converted to RRULE where possible, and by tying result bounds to date ranges rather than just listing fields.

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 opens with a specific verb and resource: 'Generate recurring date schedules using RFC 5545 RRULE.' It also covers the natural-language mode, making it immediately distinguishable from sibling tools like calculate_date or business_days.

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 implies when to use it—whenever recurring date schedules are needed, including natural-language patterns—and sets clear constraints (bounded results, no infinite recurrences). It does not explicitly name alternative tools, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool is deterministic, returns a structured result with UTC, local, and precision info, and clarifies the division of labor between LLM and tool. It does not discuss edge cases or failure behavior, but for a pure computation tool this is reasonably transparent.

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 three sentences with no wasted words. It front-loads the core purpose, then gives usage guidance, then states the return shape. Every sentence contributes useful information.

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?

Given the four well-documented parameters and the absence of an output schema, the description covers the key invocation context: when to use it, what it does, and what kind of result it returns. It could mention precision semantics or invalid-expression behavior, but it is largely complete for selection and invocation.

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 100%, so the schema already documents all parameters. The description reinforces the meaning of 'expression' with examples and mentions the output shape, but it does not add significant semantics beyond what the schema provides. Baseline 3 is appropriate.

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 states a specific verb and resource: 'Resolve a natural-language date/time expression into a deterministic ISO timestamp.' It also distinguishes the tool from sibling tools by clarifying that the LLM interprets language while the tool performs the actual temporal 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 description gives explicit guidance on when to use the tool: whenever the user mentions relative dates like 'tomorrow' or 'next Friday'. It does not explicitly name alternatives or state when not to use it, but the context is clear.

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

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

No annotations are present, so the description itself must convey behavior. It adds meaningful traits: deterministic execution, anti-hallucination purpose, and a structured-facts return. It does not document error behavior or exact output shape, which keeps this from a 5, but it is adequate for a read-only verification tool.

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?

Three sentences, front-loaded with the core function; examples are illustrative rather than filler. The final return promise is useful and earns its place.

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 tool with no output schema and no annotations, the description gives good usage context and examples, but it leaves the structure of the returned facts unspecified and does not clarify how claim relates to optional date/datetime/timezone. An agent can construct a call, but may not know how to consume the response.

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 date, datetime, timezone, and claim at roughly 75% coverage. The description's examples illustrate how claim/date/timezone are used ('3 PM London before 10 AM New York') but adds no explicit parameter constraints beyond the schema.

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?

States a specific action ('verify') on the object 'temporal claim' and gives four concrete examples that make the tool's range unambiguous. This clearly separates it from conversion/formatting siblings like convert_time and format_time.

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 gives a clear when-to-use: whenever a temporal claim needs deterministic verification to avoid hallucinations. It does not explicitly name sibling alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses determinism, reliance on the IANA database, and correct handling of zones without DST, which are meaningful behavioral traits. It does not state invalid-timezone behavior or return formatting, but the disclosed traits go well beyond a bare 'get timezone information' statement.

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?

Three short sentences with no redundant wording. The main purpose and output list are front-loaded, followed by a supporting detail (IANA) and an edge-case guarantee, all of which earn their place.

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 two-parameter query tool with no output schema, the description covers the key behavioral surfaces: what is returned, the underlying database, and a known edge case. It would be slightly more complete with explicit error behavior for invalid timezone strings, but the essentials for correct invocation are present.

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 100%, so the schema already documents both parameters. The description adds a little context by mentioning IANA and DST transitions, but it does not materially elaborate on the reference_time parameter or provide format/validation details beyond the schema.

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 specific verb ('Get') and names an exact resource ('timezone information') followed by a concrete list of outputs: UTC offset, DST status, abbreviation, and next/previous DST transitions. This clearly differentiates it from sibling tools like now or convert_time, which focus on current time or conversion rather than timezone metadata.

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 implies usage through its emphasis on DST transitions, IANA timezone data, and no-DST correctness, but it never explicitly states when an agent should choose this tool over alternatives such as convert_time or resolve_time. It also does not mention exclusions or when to avoid the tool.

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