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

No annotations provided, so the description carries full burden. It details behavior: only weekday holidays listed, inclusive/exclusive effect, 100-year span limit, and error conditions (ValueError for invalid input). This is comprehensive.

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?

Well-structured with paragraphs and bullet points (Args, Returns, Raises). Every sentence adds value, though slightly verbose. Could be tightened but overall effective.

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 5 parameters, output schema existence, and sibling tools, the description is complete. Explains return dict structure, error types, and distinguishes from siblings like get_supported_countries.

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%, but the description fully compensates. It explains each parameter: date format, country case-insensitivity, inclusive default, subdiv case-sensitivity and relation to get_supported_countries. No ambiguity remains.

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's purpose: 'Count business days and list weekday holidays between two dates.' It distinguishes itself from sibling tools like is_business_day and list_holidays by combining counting and listing.

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 explicit use cases: 'measure working-day spans for SLAs, delivery windows, or payroll periods.' It explains what holidays are included/excluded but does not mention when to avoid this tool or suggest alternatives like is_business_day for single date checks.

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 full burden and discloses that it does not consult holiday calendars, the output format (date, timezone, day_of_week, iso_week), and that it raises a ValueError for invalid timezones.

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 well-structured with 'Args', 'Returns', 'Raises' sections and is concise, providing all necessary information without unnecessary words.

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 simplicity of the tool and the presence of an output schema, the description is complete, explaining return values and error conditions. Context signals show 1 parameter and no complexity, so the description fully addresses them.

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 0%, but the description compensates by explaining the timezone parameter with examples, default value, and valid format (IANA timezone name). It adds meaning 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 states exactly what the tool does: return the current date in a given IANA timezone. It is distinct from sibling tools like business days or holiday calculators.

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 explicitly suggests using this tool when a stable, server-computed 'today' is needed before calling other tools. It does not explicitly state when not to use it or list alternatives, but sibling names provide context.

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 provided, so the description carries full burden. It discloses critical behaviors: subdivision codes are case-sensitive and must be used verbatim, country codes are case-insensitive, and subdivisions may be empty for some countries or due to library errors—all beyond basic functionality.

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?

Description is well-structured: first sentence for purpose, then usage guidance, then important behavioral notes, then return format. Every sentence adds value without redundancy.

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?

Despite no parameters and no annotations, the description is thorough. It explains the return structure (countries list with code, name, subdivisions, total) and addresses edge cases (empty subdivisions, library errors), making it complete for agent interaction.

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?

Tool has zero parameters, so baseline is 4. Description does not need to add parameter info, but it does mention how subdivision codes (from other tools) are used, which is helpful context.

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?

Description clearly states 'List all countries supported by the holidays library, with subdivisions' with a specific verb and resource. It differentiates from sibling tools (which focus on business days, dates, holidays) by positioning itself as a discovery tool.

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?

Explicitly advises using this tool 'before calling any country-aware tool', and explains that it provides valid ISO codes and subdivision codes for other tools, effectively guiding when and why to use it.

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 full burden for behavioral disclosure. It notes case-sensitivity, return value structure, and raises ValueError for unknown countries. It does not mention performance or rate limits, but for a simple lookup tool, this is largely sufficient.

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 well-structured with sections: main purpose, usage guidance, important note, example, formal Args/Returns/Raises. It is concise yet comprehensive, with no redundant sentences.

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 simplicity (single parameter, straightforward lookup), the description fully covers purpose, usage, parameter semantics, return format, and error handling. The inline output schema compensates for the missing structured output schema.

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 0%, so description must add meaning. It specifies that `country` is an ISO 3166-1 alpha-2 code, case-insensitive, and normalized to uppercase. This is valuable context beyond the bare schema type.

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 lists subdivision codes and aliases for a country's holiday calendar. It specifies the action (list), resource (subdivision codes/aliases), and scope (per country). It distinguishes from siblings by mentioning its role in discovering valid `subdiv` values for other country-aware holiday tools.

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 explicitly advises using this tool before calling other country-aware tools like `is_business_day`, `list_holidays`, and `next_business_day`. It provides guidance on case sensitivity and normalization of subdivision codes, and includes an example for clarity.

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 fully handles behavioral disclosure. It explains what constitutes a business day (not weekend, not holiday), notes case-sensitivity of subdiv, states that omitting subdiv only considers nation-wide holidays, and mentions that category filtering is not supported. It also lists raised ValueError conditions.

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 front-loaded with the main purpose and structured with Args/Returns/Raises sections. It is reasonably concise, though the subdiv description includes an example that could be slightly shortened. Overall, 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?

Given the tool's moderate complexity and missing annotations, the description is complete. It explains all parameters, the return value (dict with specific keys), and error conditions. The output schema exists (implied by the description's Returns section), so no further detail is needed on return values.

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 0% schema description coverage, the description compensates fully. It explains the ISO 8601 date format, case-insensitivity of country code, case-sensitivity of subdiv with an example, and the effect of omitting subdiv. This adds meaning far beyond the bare schema types.

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 'Check whether a date is a business day for a given country (optionally a subdivision)' with a specific verb and resource. It distinguishes from sibling tools like 'business_days_between' and 'list_holidays' by focusing on a single date check.

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 explicitly says 'Use this when an agent needs to know if a specific calendar date is a working day'. While it doesn't explicitly list alternatives, the context from sibling tool names implies when not to use it (e.g., for date ranges use 'business_days_between').

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 fully explains behavior: walking backward, skipping weekends and holidays, handling errors, and subdiv case-sensitivity. This leaves minimal ambiguity for the agent.

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 well-structured with paragraphs for overview, then standard Args/Returns/Raises sections. Every sentence adds value without redundancy.

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 (4 parameters, output schema, error handling), the description covers all necessary aspects: use case, algorithm, parameter details, return format, and error conditions. It is fully complete.

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 0%, so the description compensates by detailing each parameter: year (4-digit), month (1-12), country (ISO code, case-insensitive), subdiv (optional, case-sensitive, reference to get_supported_countries). This adds value 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 states the tool returns the last business day of a given month, with specific use cases. However, it does not explicitly differentiate from sibling tools like previous_business_day or next_business_day, which could cause confusion.

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 explicit use cases (end-of-month billing, reporting, settlement) and mentions the algorithm (walks backward). It lacks when-not-to-use or alternative tools, but the guidance is clear enough.

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 fully covers behavioral aspects: sorted output, inclusion of weekend holidays, case-insensitive country normalization, case-sensitive subdiv, unsupported category filtering, and error conditions (ValueError). This exceeds minimal disclosure.

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 well-structured with clear sections for arguments, return value, and errors. Every sentence adds meaningful information without redundancy. It is appropriately sized for the tool's complexity.

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 covers all aspects: input constraints, output structure, error handling, and behavioral notes. Given the output schema exists, the description still explains the return format, ensuring completeness. No gaps remain for this 3-parameter tool.

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 0%, so the description must compensate. It explains each parameter in detail: year format, country code case-insensitivity and normalization, subdiv optionality with examples and limitations, and provides concrete example ('country=DE, subdiv=BY'). This adds significant value beyond the raw 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 states the tool's purpose: listing all holidays for a given year and country, sorted by date. It uses a specific verb ('list') and resource ('holidays'), and distinguishes from sibling tools like 'business_days_between' and 'is_business_day' by focusing on full holiday enumeration.

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 explicit usage scenarios ('for display, planning, or cross-referencing') and mentions that holidays on weekends are included. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an agent to decide.

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 fully carries the burden. It discloses that weekends and public holidays are skipped, that inclusive flag affects whether the start date qualifies, that subdiv filters by region, that ValueError is raised on invalid inputs, and that there's a ~10-year search limit. This is thorough behavioral disclosure.

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 well-organized with a clear first sentence, bullet-pointed args, and sections for returns and raises. It is concise without being terse—every sentence adds value. No redundant or extraneous text.

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?

Despite having 4 parameters, 0% schema coverage, and no annotations, the description is complete. It covers input details, behavior, output keys, and error conditions. The output schema exists (not shown but referenced in description), so description doesn't need to detail return values further. It references get_supported_countries for subdiv values, showing awareness of related tools.

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 0%, so the description must compensate. It does so by specifying format for 'date' (ISO 8601), case-insensitive normalization for 'country', behavior of 'inclusive' (True/False default), and 'subdiv' with an example (case-sensitive, optional, region-specific). This adds significant meaning beyond the raw 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 states 'Return the next business day on/after (inclusive) or strictly after date' and explains it skips weekends and public holidays. It is specific about the resource (business day) and action (return next), and implicitly distinguishes from siblings like is_business_day or previous_business_day.

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 says 'Use this to move forward to the soonest working day', which is a clear usage context. However, it does not explicitly mention when not to use or point to alternatives like is_business_day for checking a specific date. The context signals list sibling tools, but the description itself lacks explicit exclusions.

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, but the description fully discloses behavior: it skips weekends and public holidays, has an inclusive option, raises ValueError for invalid inputs, and limits search to ~10 years. It does not mention idempotency, but that is implied for a read-only 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?

The description is well-structured with Args, Returns, Raises sections. It is front-loaded with the main purpose. Though lengthy, each sentence adds value and no redundancy.

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 complexity (4 params, no annotations, but output schema exists), the description is very complete. It covers input, output, errors, and edge cases (inclusive, subdiv optional, 10-year limit).

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 0%, but the description provides detailed semantics for all 4 parameters: date format, country code, inclusive boolean, subdiv with reference to get_supported_countries. This adds significant value 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 states it returns the previous business day on/before or strictly before a given date. It specifies skipping weekends and public holidays, distinguishing it from siblings like next_business_day and business_days_between.

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 explicitly says 'Use this to move backward to the most recent working day' and contrasts with other tools implicitly. It does not explicitly 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.