ベストカレンダー 暦データ

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

With readOnly/destructive annotations already covering safety, the description adds genuine behavioral substance: the base date is not counted (a classic off-by-one pitfall), business-day mode excludes weekends and holidays by default, and closed weekdays, obon, year-end, and per-date overrides are supported. It stops short of stating the return value or how conflicting open/closed date lists resolve.

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 compact sentences lead with the core operation and mode, then add the non-obvious 'base date not counted' rule and the negative-N case. No filler, and the most decision-relevant information comes first.

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 nine-parameter date-arithmetic tool with no output schema, the description covers the behavioral model well but never says what comes back (presumably a YYYY-MM-DD string) or how holidays interact with explicit closed_weekdays/open_dates precedence. Range constraints are delegated to the schema, so the remaining gap is modest but real.

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 each of the nine parameters is already documented including ranges and defaults. The description adds only conceptual framing (business mode bundles the holiday/obon/nenmatsu/closed-weekday switches) and the negative-n convention, which is the baseline expectation when the schema does the heavy lifting.

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 operation: shifting a date forward/backward by N calendar or business days, with explicit mention of the business-day mode and negative-N reversal. This clearly separates it from siblings like count_days (measuring spans) and check_business_day (testing a single date), though it never names those alternatives 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?

Usage is implied rather than prescribed: the parenthetical '締め切りの逆算' hints at the negative-N deadline back-calculation scenario, and 'business: true' signals when to switch modes. There is no explicit statement of when NOT to use this tool versus count_days or find_dates, leaving routing to inference.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context: it reads by rules, does not guess when a question cannot be parsed, and returns a 'could not read' message with example phrasings. It also discloses that the response includes evidence tools/arguments and sources.

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 definition is compact: two sentences with no filler. The examples are dense but earn their place by clarifying scope, and the core behavior is front-loaded before the failure-mode sentence.

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 an aggregator tool with one natural-language parameter, no output schema, and safety annotations, the description is largely complete: it covers inputs, outputs, evidence returned, and failure behavior. It leaves a minor gap by not explicitly routing the agent between this tool and the individual sibling 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 100%, so the single question parameter is already documented. The description adds meaningful scope beyond the schema by giving four concrete example question types, showing that the parameter accepts natural-language queries about dates, rokuyo, solar terms, and business-day offsets.

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 action (returns in one go) for a specific resource (one Japanese calendar question) and names the return components: answer, evidence tools/arguments, and sources. The examples clarify the calendar domain and breadth. It does not explicitly name sibling tools, so it falls short of full sibling differentiation.

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 examples imply when the tool is useful for natural-language calendar questions, and the failure behavior describes one boundary condition. However, it does not say when to use this aggregate tool versus specific siblings like add_days, find_dates, or get_rokuyo_hours, nor does it state exclusions beyond unreadable questions.

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?

Annotations already establish the read-only, closed-world, non-destructive profile, and the description adds real substance on top: what comes back (休み理由 and 祝日名), the extra previous/next business day output for single dates, and the fact that the closure rule set is configurable with a stated default of weekends plus holidays. It does not cover error behavior or input conflicts, but it clears the lower bar set by the annotations.

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 ordered from core output, to the single-day special case, to rule configuration — front-loaded and free of filler. It is dense but every clause carries information; only the rule enumeration in the last sentence borders on restating parameters.

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 9 optional parameters and no output schema, the description does necessary work by naming the returned fields and the next/previous business day output that an agent could not otherwise predict. It is not fully complete: it is silent on what happens if `date` and `start`/`end` are supplied together, and on any error/limit conditions beyond the 62-day cap.

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% and the schema already documents each date format, per-flag defaults, and the meaning of closed_weekdays/open_dates/closed_dates, so the description largely restates structured data. The one genuine addition is the 62-day maximum span, a constraint that is absent from the schema; the either/or relationship between `date` and `start`/`end` is only hinted at.

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 first sentence states a specific operation (business-day vs. holiday determination) with its scope boundary (a single date or a span up to 62 days) and its return semantics (reason and holiday name). An agent can distinguish it from siblings such as list_holidays or find_dates on the basis of this alone, although 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 distinguishes the one-day case (which additionally yields previous/next business day) from the range case, which is useful routing context, and states the default rule set. However, it never says when to prefer this tool over list_holidays or count_days, and gives no exclusion conditions; the usage guidance is implied rather than explicit.

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?

Annotations already cover the read-only, non-destructive, closed-world profile, so the description's job is to add semantics — which it does by pinning the supported range (1926–2080) and noting that a year falling on a 改元 returns both era names. It stops short of describing how the two result shapes differ or how errors surface, keeping it below 5.

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?

One compact sentence front-loads the primary year-conversion case, then the date case, then the argument rule. No filler and no repetition of the title.

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 no output schema, the description usefully enumerates the returned fields for each mode (和暦・干支・九星 vs 本命星・月命星), which is essential. Minor gap: it does not say whether both parameters may be passed at once or how the two result shapes are keyed.

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 only 50% (year has bounds but no description), and the description compensates: it restates the 1926–2080 range and adds the critical constraint that exactly one of year or date should be supplied, despite both being optional in the schema. It could add date-format expectations more explicitly, but the schema already carries YYYY-MM-DD.

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) plus the three target resources for each mode (和暦・十干十二支・九星 for a year; 和暦・本命星・月命星 for a date). No sibling tool in the list does era/eto/kyusei conversion, so an agent can select it unambiguously.

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 tool's niche is narrow enough that the intended use is implied, and the year/date either-or instruction steers invocation. However, it never states when to prefer this over siblings (e.g. get_koyomi_day) or what happens if neither/both arguments are supplied, so guidance is implicit rather than explicit.

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?

The annotations (readOnlyHint true, destructiveHint false) already establish that the tool is a safe read-only calculation. The description adds context the annotations do not: which days are excluded from the business-day count (weekends, holidays, closed weekdays, Obon, New Year, individual closures and openings), and which counting rules apply. It does not describe the response shape or ordering.

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 the core purpose stated first, followed by the counting rules and then the edge-case semantics. The final sentence is dense and convoluted, and some of the content simply restates the per-parameter documentation in the input schema, but overall it reads cleanly and stays on topic.

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 an 11-parameter tool with complex holiday logic and no output schema, the description explains the inputs well but never says what the tool returns. The caller has to infer the response shape, presumably total days and business days, which is the biggest gap given that multiple counts look plausible.

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 handles the bulk of the parameter documentation and the baseline score of 3 applies. The description goes slightly beyond the schema: it clarifies business_count_start (whose schema text is just one line) and explains the concrete effect of that flag, so it adds some semantic value.

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 names a specific verb (counting) and a specific resource (days and business days between two dates), and spells out the holiday/weekend rules that define the calculation. It does not differentiate itself from the available siblings such as check_business_day, add_days, or find_dates; its only pointer is to an external web tool (/tools/date-calculator).

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 one concrete usage recipe – counting the business days in a month by setting start to the 1st, end to the last day, and business_count_start: true – and says the counting rules match /tools/date-calculator. However, it never says when to choose this tool over check_business_day or add_days, and it never states when this tool is not 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavior beyond that: the 366-day maximum search span (not present in the schema) and the mechanism by which conditions are combined and offset. It does not state what the response looks like (list vs. count), which keeps it from a 5.

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 purpose is stated in the first clause, followed by supported condition types, combination semantics, the offset mechanism, and one concrete example. Every sentence adds information an agent needs, and nothing is repeated from the schema verbatim.

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 five parameters and three parallel nested condition arrays, the description supplies the combination logic, the search-span limit, and offset semantics, which is enough to call it correctly. The remaining gap is the return shape (list of dates, count, per-condition matches) and its relationship to search_lucky_days; with no output schema, a sentence on results would complete it.

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%, and each nested condition field is documented in the schema with enums and examples, so the baseline is 3. The description does add meaning for all/any/none (すべて/どれか/除く) and for offset_days with the '翌日が満月'/'前日が祝日' illustrations, which the terse schema wording alone conveys less clearly.

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 ('期間（366日まで）の中から、条件に合う日を探す'), and then enumerates the condition families (六曜・吉日・曜日・祝日・二十四節気・月相・日干支), so an agent immediately knows this is a multi-criteria date search, not a single-day lookup. It falls short of 5 because it never distinguishes itself from the sibling search_lucky_days, which plausibly overlaps with this 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?

The description gives concrete guidance on how to invoke the tool: combine conditions with all/any/none, and use offset_days for shifted conditions such as '翌日が満月'. The worked example ('2027年の大安の土日で不成就日でない日') shows exactly the kind of query this tool is for. However, it never states when to prefer this over search_lucky_days or get_koyomi_day, and gives no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the data is checked against 国立天文台・内閣府 published values and covers 1926–2080, telling the agent how authoritative the results are and where the boundary lies.

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 front-loaded sentence with the subject ('指定した日の暦') first, followed by a compact enumeration and then provenance. The dense item list is justified because it doubles as the return-value inventory in the absence of an output 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 no output schema, the enumeration of returned fields is exactly what the agent needs to judge whether this tool answers its question, and the stated year range and data provenance close the remaining gaps. Only explicit sibling routing is missing.

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?

One parameter with 100% schema description coverage — the schema already specifies the YYYY-MM-DD format and the 1926-01-01〜2080-12-31 bounds. The description only restates that range in prose and adds no format or edge-case guidance beyond it, so the baseline 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 makes clear this returns the full calendar record for a single given date, and enumerates the specific contents (和暦, 旧暦, 六曜, 二十四節気, 月齢, 祝日, 九星, etc.), which distinguishes it from narrower siblings like get_moon_phases or get_solar_term_times. It never states an explicit verb ('returns'/'gets'), but the resource and scope are unambiguous.

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?

Usage is only implied: the presence of the date parameter and the breadth of the returned fields suggest 'call this when you need a single day's complete almanac.' There is no explicit when/when-not guidance and no routing to siblings such as get_moon_events or get_rokuyo_hours for the specialized data it overlaps with.

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?

Annotations already declare readOnly, non-destructive and closed-world, so the safety bar is met; the description adds the output shape (year's date, next date, days remaining, definition, basis), which matters since no output schema exists. It does not state formatting or what happens for unknown names, keeping it at 4.

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 resource and its output fields, then the alternate query mode. The example lists are long but each example teaches the accepted name vocabulary, so they earn their 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 3-parameter lookup with no output schema, the description covers what is returned and how year vs from_date behave, which is enough to call it correctly. Minor gaps remain around failure behavior for unknown or ambiguous names.

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 67%, and the description adds meaning beyond it: it clarifies that year selects a specific year while from_date (default today) yields the next occurrence, an interaction the schema does not express. The name parameter's accepted forms (読み/別名/slug) are left to the schema text.

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+resource: look up a calendar event by name (with concrete examples of the name vocabulary) and return its date, next occurrence, countdown, definition and 根拠. The 'by name' framing implicitly separates it from date-based siblings like find_dates or search_lucky_days, 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?

The final sentence tells the agent which parameter to reach for (year = that year, from_date defaults to today = next occurrence), which is real operational guidance. However, there is no statement of when to prefer this tool over find_dates / search_lucky_days / get_koyomi_day.

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?

アノテーションが readOnlyHint=true、openWorldHint=false、destructiveHint=false を宣言しており、安全性の説明はアノテーションに任せられる。その上で、対象期間（1926〜2080）や日付範囲の上限366日、返される内容（食の種類・日本での見え方・時刻・スーパームーン）といった振る舞いの文脈を記述しており、追加価値がある。

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?

2文のみで、対象（月食・スーパームーン）を先頭に、次に指定方法を置く構成で無駄がない。すべての文が情報を提供している。

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?

出力スキーマはないが、説明が返却内容（食の種類・日本での見え方・時刻・スーパームーン）を伝えている。ただし、必須引数が0個であるにもかかわらず引数無しで呼んだ場合の挙動（全期間か、エラーか）が説明されておらず、わずかな不足がある。

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?

スキーマの説明カバレッジは67%で、year パラメータにはスキーマ上の説明がないが、説明文が同じ範囲（1926〜2080）を補っている。さらに、スキーマにはない「start と end は366日まで」という制約と「year か start/end のいずれか」という排他的な指定方法を示しており、スキーマ以上の意味を加えている。

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?

具体的な動詞と対象（月食一覧とスーパームーン一覧）を示し、皆既・部分・半影といった対象範囲や日本での見え方・時刻まで明示している。ただし、類似する get_moon_phases という兄弟ツールとの違いを明示的に述べていないため、4点とする。

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?

「year で指定するか、start と end で指定する（366日まで）」と指定方法の分岐は示しているが、どちらをいつ使うべきか、また get_moon_phases など他のツールを選ぶ条件は示されていない。引数が0個の場合はどうなるかも不明であり、暗黙の使用法にとどまる。

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?

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds genuinely new context: the data is cross-checked against the National Astronomical Observatory's official almanac, timestamps are JST to the second, the supported year range is 1926–2080, and a start/end window may not exceed 366 days.

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, front-loaded with what is returned, then how to scope it, then a provenance note. No filler and no repetition of the title.

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?

There is no output schema, so the description carries the burden of describing the result, which it does at a high level (a list of the four phase instants, JST, second precision). The exact response shape (e.g. grouping by month, field naming) is left unstated, but nothing needed to call it correctly is missing.

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 only 67% — the year parameter has no schema description at all — and the description compensates by giving its range (1926–2080). It also adds a constraint not present anywhere in the schema: start/end spans are capped at 366 days. It does not state whether year and start/end are mutually exclusive, which is a remaining gap.

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 resource (the exact instants of new, first-quarter, full and last-quarter moon) with precision and timezone, so an agent knows exactly what comes back. It does not explicitly distinguish itself from similar siblings such as get_moon_events or get_sun_moon_times, so the sibling differentiation is only implicit.

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 explains the two query modes (year, or start+end up to 366 days), which is real usage guidance. However, it never says when to prefer one mode or why an agent would choose this tool over get_moon_events/get_sun_moon_times, and there are no 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?

Annotations already establish read-only, non-destructive, closed-domain behavior, so the bar is lower; the description usefully adds that 明六つ/暮六つ follows the NAOJ definition and that prefecture defaults to Tokyo. It does not say anything about how location shifts the results, invalid-datetime behavior, or the shape of the returned values, and with no output schema that gap matters.

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-loaded with what is returned, with parenthetical examples that earn their place by making the unfamiliar 刻 naming concrete. No filler; only the trailing location clause is slightly 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?

For a simple two-parameter read-only tool this is close to sufficient, and the description does enumerate the three output categories. However, with no output schema the description still leaves the return format (single string vs. structured fields, whether sun-event times are included) unspecified, so an agent cannot predict the response shape.

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; both schema fields already carry format descriptions. The description only restates that datetime is Japan time and that prefecture defaults to Tokyo — the latter duplicates the schema verbatim — without explaining how prefecture affects the computed 明六つ times.

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?

Names a specific verb (返す) and a concrete, unusual resource set: 明六つ・暮六つ, 不定時法の刻, 十二辰刻, with examples (暮六つ・暁九つ, 丑三つ時). This clearly separates it in spirit from siblings such as get_sun_moon_times or get_rokuyo_hours, but no sibling is named, so it stays at 4.

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?

Input expectations are stated (Japanese-time datetime, prefecture defaults to Tokyo), which implies the use case, but there is no explicit framing of when to pick this over get_rokuyo_hours or get_sun_moon_times, and no exclusions or prerequisites. Usage is inferable rather than guided.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety behavior is covered. The description adds useful context that results are based on 暦注の慣行 and gives examples of time-specific fortune, but it does not describe return structure, timezone handling, or other limitations.

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: it states the primary result first, then adds brief examples. Every sentence contributes useful meaning without repetition.

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 one-parameter read-only lookup tool, the description gives enough context to understand the result type and basis. However, because there is no output schema, it could more explicitly describe the return shape or per-time-period structure.

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%, and the single date parameter is fully documented with format YYYY-MM-DD and a valid range. The description only says 指定した日の, adding no parameter semantics beyond the schema, so the baseline 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 that the tool returns the rokuyo for a specified date plus good/bad fortune by time period, with concrete examples such as 先勝 and 赤口. It is specific about resource and output content, though it does not explicitly distinguish itself from siblings like get_koyomi_day or search_lucky_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?

Usage is implied by the tool name and the description of returning hourly fortune for a date, but there is no explicit statement of when to use this tool versus alternatives. No exclusions or alternative tools are mentioned.

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?

Annotations already declare a safe read-only, closed-world operation, so the description adds genuine context beyond them: timezone (JST), precision (seconds plus minute-rounded values), and the provenance claim of being verified against the NAOJ 暦要項. It does not cover edge behavior such as supplying both year and start/end, or what is returned when a span crosses a year boundary.

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?

Five short sentences, each carrying a distinct fact (what is returned, precision, examples, input modes, trustworthiness), front-loaded with the returned value. No filler or repetition of the title.

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 no output schema and zero required parameters, the description should say what the default invocation returns and what shape the response takes; it says neither. Coverage of the input modes, timezone and precision is otherwise solid for a simple read-only lookup.

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?

Beyond the 67% schema coverage, the description contributes two facts the schema does not: the mutual exclusivity of the two modes (year vs. start+end) and a maximum span of 366 days, which the schema never states for start/end. It leaves the zero-required-parameter case (what happens with no arguments) unexplained.

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 the resource precisely: the date-times of the 24 solar terms' setsu-iri (節入り), with concrete examples (立春・春分・夏至・秋分・冬至) that anchor what a 'solar term time' means. It does not explicitly contrast itself with siblings such as get_sun_moon_times or get_moon_events, though the scope is distinct enough to infer the difference.

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 tells the agent how to scope a query ('year か、start と end') and implicitly when this tool applies (you want the clock time of a solar-term ingress). It never states when NOT to use it or names an alternative sibling for related calendrical queries, so usage is implied rather than guided.

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?

Annotations already declare read-only, closed-world, and non-destructive behaviors, so the bar is lower. The description still adds real information: results are in Japan time, based on a representative point per prefecture rather than a precise location, and computed under the NAOJ '各地のこよみ' definition.

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 sentences, front-loaded with the full list of returned values, followed by scope and the astronomical reference standard. Each clause earns its place, with no 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?

It covers inputs beyond the schema and states the definitional basis, but with no output schema it doesn't specify the return format (for example, 'HH:MM' strings), error behavior for out-of-range dates or unknown prefecture names, or how it differs from the overlapping moon sibling. The definition is adequate but leaves real gaps.

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%, with the date range and prefecture examples already documented in the schema. The description adds only the useful nuance that prefecture selection maps to a representative point (so results are approximate), which is a modest but genuine addition 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 names the concrete resources returned (sunrise, sunset, moonrise, moonset, and culmination) and scopes them to a given date and prefecture, so the agent knows exactly what this tool produces. It does not distinguish itself from the sibling `get_moon_events`, which appears to cover overlapping moon data.

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 only implies usage ('specified date/prefecture, Japan time') and never states when to choose this tool over `get_moon_events` or `get_solar_term_times`. There are no exclusion rules and no prerequisites, leaving the agent to infer which of the overlapping tools to call.

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?

Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context beyond those: the official-source verification, the inclusion of substitute and citizens' holidays, and the 366-day maximum span.

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 compact sentences: the first front-loads scope and provenance, the second specifies the parameter modes and limits. No redundant or filler 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?

For a simple read-only list tool with no output schema, the description covers scope, provenance, date range, and parameter selection modes. It does not explain what happens when no parameters are supplied (all parameters are optional) or the return format, which are the remaining gaps.

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 67%, and the schema itself documents start/end formats and year min/max. The description adds meaning beyond the schema by stating the 'year or start+end' selection model and the 366-day maximum span, which is not encoded in 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 a specific verb and resource: a list (一覧) of Japanese national holidays, substitute holidays, and citizens' holidays, with provenance (verified against Cabinet Office published values). This clearly separates it from siblings like check_business_day or search_lucky_days without needing their schemas.

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 explains the two supported query modes — by year or by start/end range — and gives the range limits. It does not explicitly say when to prefer this over related tools such as check_business_day, but the context of use 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavior — a 200-result cap — but does not say what happens on overflow (silent truncation? ordering of which 200?), which materially affects how the agent should scope queries.

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, no redundancy: purpose first, then optional narrowing, then the result-count limit. Every sentence carries operational 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?

With 6 parameters and no output schema, the definition should clarify the return shape (a list of dates with which conditions matched?) and default ordering; it does not. Also silent on the default match=any behavior, which changes result semantics considerably.

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 baseline is 3. The description does add one constraint absent from the schema — the start–end span must be ≤366 days — but leaves the match (any/all) parameter and the kinds vocabulary entirely to 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 verb (探す) and resource (吉日/六曜条件に合う日), with the 366-day scope and matching criteria spelled out. It doesn't name or contrast any sibling (e.g. find_dates, check_business_day), so an agent must infer differentiation from the criteria list alone.

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?

Usage is implied by the criteria description (rokuyo + lucky-day kinds, optional weekday narrowing, excluding 不成就日), but there is no explicit when-to-use vs. when-not guidance and no pointer to which sibling to use for a single-date lookup or a non-lucky search.

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