生活即時查詢

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

With no annotations, the description carries the full burden. It usefully discloses the return contents (win status, prize category, amount, redemption period), which is valuable given no output schema. It says nothing about permissions, rate limits, or whether the period defaults matter behaviorally.

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 that gives the purpose, the required input, and the return payload with zero wasted words. Nothing extraneous.

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 lookup with full schema coverage, the description covers purpose, input, and return values. It is nearly complete, lacking only sibling differentiation and the period-default behavior, which are minor for this tool's complexity.

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 both parameters are already documented in the schema. The description reiterates the 8-digit format of 'number' but says nothing about the 'period' parameter or its 'latest period' default, adding little 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 verb and resource (對統一發票 / check uniform invoice) plus the concrete result set (win status, prize category, amount, redemption period), so an agent knows exactly what it does. However, it never names or differentiates from the sibling check_lottery or get_invoice_numbers, leaving potential ambiguity.

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?

Implies usage by saying 'input an 8-digit invoice number,' which sets the precondition for invocation. There is no explicit when/when-not guidance and no reference to alternative tools like check_lottery, so usage context is only inferred.

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; it does usefully disclose the output shape (matched count, prize, per-bet payout, redemption deadline), which is real behavioral information. However, it says nothing about whether the call is read-only, what a missing period defaults to, or how errors (e.g. invalid numbers) are handled.

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 compact sentence that front-loads the verb and then lists the four return values. No filler, 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?

For a 4-parameter tool with no output schema and no annotations, the description covers the output side well but leaves input semantics (period, second) and read-only behavior unstated. Adequate but with clear gaps against the module's complexity.

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 only 25% (only 'second' is documented). The description mentions only game and numbers, leaving 'period' (drawing period) and 'second' (威力彩 second zone) largely unexplained in prose, so it does not compensate for the sparse 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 ('對彩券' / check lottery) and even enumerates the return payload (matched count, prize tier, payout, redemption deadline). It is clearly a computation over a user's own numbers, but it never names or contrasts with the sibling get_lottery_results, leaving the agent to infer the split.

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?

There is no explicit when-to-use guidance and no mention of the natural alternative, get_lottery_results. The only usage signal is the phrase '輸入遊戲與號碼', which implies the caller supplies their own ticket, but this is inference rather than stated 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 provided, the description carries the full behavioral burden. It helpfully discloses the return contents (amount, application method, official links) and the verb 查詢 implies a read-only lookup, but it never explicitly states read-only safety, data freshness, or whether any authentication is needed.

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 states the resource, the category scope, and the returned information with no filler. Every clause 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 simple two-parameter search tool with no output schema and no annotations, the description adequately covers what is searched and what is returned. The only notable gap is how keyword and category interact when both are supplied, which an agent might need to know.

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 both parameters are already documented in the schema, including the keyword example and the category enumeration. The description's parenthetical category list mirrors the category parameter without adding new semantic detail, 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 names a specific verb (查詢) and resource (台灣中央政府民眾補助津貼), then enumerates the covered subsidy categories, making the scope unmistakable. No sibling tool overlaps with this domain, so the agent can route to it directly without opening the schema.

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 purpose itself implies usage (look up government subsidies), but there is no explicit guidance on when to use keyword versus category, whether the two can be combined, or when to prefer this over any alternative. The usage is inferable rather than stated.

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 exist, so the description carries the full burden. It usefully discloses the return shape (fuel grades, NTD-per-liter units, weekly delta) in the absence of an output schema, but says nothing about data freshness/caching, update cadence, or that the call is a non-mutating read.

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 densely packed sentence that front-loads the source and resource, then lists returned fields and units. No filler, no 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?

With no output schema and no annotations, the description does the heavy lifting well by enumerating returned fields and units. It stops short of stating data currency mechanics (when 'this week' refreshes) or that the result is a read-only snapshot.

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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is argument-free; baseline 4 applies. The schema is an empty object, consistent with the description's 'this week' framing.

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 ('取得台灣中油本週油價') and enumerates exactly what is returned: 92/95/98 unleaded, alcohol gasoline, super diesel, per-liter NTD, plus week-over-week change. The sibling set (lottery, invoice, holiday tools) covers entirely different domains, so cross-tool confusion is essentially impossible.

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 stated: '本週油價' signals a current-week lookup with no parameters, so an agent can infer when it applies. However, there is no explicit when-to-use framing, and no note on whether historical weeks are obtainable elsewhere or whether this is the only fuel-price source.

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 does disclose the authoritative data source (人事行政總處辦公日曆) and the content categories covered, but says nothing about return shape, pagination, supported year ranges, or behavior for out-of-range years. For a read-only lookup tool that is acceptable but not rich.

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 covering the resource, the data source, and the special cases, with no filler. It is dense but readable; the only mild cost is that the embedded clause about 'today' blurs scope with the is_holiday sibling.

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 lookup with one optional parameter and no output schema, the description covers the data source and the categories returned, which is what an agent needs to call it. It stops short of explaining how years are validated or what happens for unsupported years, but nothing critical 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 description coverage is 100% and the single optional 'year' parameter is already documented in the schema. The description's mention of today's status and the next long weekend hints at the default behavior when year is omitted, but adds no syntax or format detail beyond the schema. 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 names a specific verb and resource: retrieving Taiwan national holidays, 連假, and 補班日 from the 人事行政總處 office calendar, plus today's holiday status and the next long weekend. That is clearly distinguishable from the other siblings (invoice, lottery, fuel). However, it does not distinguish itself from its closest sibling is_holiday, whose scope (today's holiday status) is explicitly folded into this tool's description.

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 tool returns holiday calendars and 'today' status, so an agent can infer it is the general holiday-lookup. There is no explicit statement of when to prefer this over is_holiday, nor any exclusion or prerequisite guidance, despite is_holiday being an obvious alternative.

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 disclosure burden. It usefully states the exact payload (three prize tiers plus the redemption period), which tells the agent what it will receive, and 取得 implies a read-only lookup. It says nothing about data freshness, caching, or whether historical periods beyond the default are retrievable, which is a modest gap for a low-risk read 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?

A single front-loaded sentence that names the resource, the payload, and the redemption-period detail with zero filler. Nothing could be removed without losing 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?

For a one-parameter, no-annotation read tool with no output schema, the description covers the essentials: what it fetches and what the result contains. It leaves open whether historical periods are supported and how results are structured, but those are minor for this tool's complexity.

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 period parameter is already documented with its format example (115-05-06) and default-to-latest behavior. The description adds no format or 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?

States a specific verb (取得/get) and resource (台灣統一發票中獎號碼) and enumerates the prize tiers returned (特別獎、特獎、頭獎) plus the redemption period, so the agent knows exactly what data comes back. It does not, however, explicitly distinguish itself from siblings like check_invoice or get_lottery_results.

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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternative tools such as check_invoice or get_lottery_results. The agent must infer usage purely from the tool name and the described payload.

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 behavioral burden. It states what data is returned (numbers and prize amounts) but omits read-only nature, data freshness, authentication needs, default behavior when game is omitted, and output format.

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 a single, front-loaded sentence with no redundant or filler content. Every part of the sentence contributes to the purpose.

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 required parameters, the description gives only a high-level view of return data and does not explain what happens when game is omitted or how period should be formatted. It is minimally adequate but leaves 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 50%. The description adds meaning to the game enum by naming the three lottery types in Chinese (大樂透, 威力彩, 今彩539), which helps map enum values like lotto649. However, it does not clarify period format or default behavior beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb (取得) and resource (開獎號碼與各獎項獎金) for three named lottery games. It does not differentiate from the sibling tool check_lottery, which could also relate to lottery checking, leaving some ambiguity.

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 explicit when-to-use guidance or alternatives are provided. The description implies it is used to fetch results, but does not say when to prefer it over check_lottery or how to handle missing parameters.

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 discloses that the data is planned/scheduled outage announcements and points to Taipower's address query link, but says nothing about coverage limits, recency of data, whether unplanned outages are included, or what the response contains.

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 compact single line that front-loads the resource and query scope, then the trigger scenario, then the helper link. Efficient, though the trailing URL fragment is somewhat dense.

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-param read tool with no annotations and no output schema, the description covers the basic purpose and trigger condition but omits data freshness, coverage of unplanned outages, and return-shape expectations. Adequate but with clear gaps given reliance on the description alone.

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 concise examples for county and district, so the schema already documents both parameters. The description adds only that filtering is by county (依縣市), which is marginal beyond the schema and does not fully explain the district parameter's relation.

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: querying Taipower's planned/scheduled work outage announcements by county. This distinguishes it from the sibling get_water_outages, but does not explicitly call out the contrast. Clear purpose but minimal sibling differentiation beyond the resource name.

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 implied use case ('when the user asks whether the power will be out tomorrow') and an address lookup link. There is no explicit when-not-to-use guidance or mention of alternatives such as get_water_outages, so usage is only implied.

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 disclosure burden. It usefully reveals coverage (two water utilities plus drought warnings), but says nothing about behavior: whether both params are optional, what is returned when no county/district is supplied (whole island?), or the freshness/source of the announcements. For a query tool this is adequate but incomplete.

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: the first front-loads purpose and scope, the second gives usage triggers. No filler, no restatement of the name, and the most important information leads.

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 no annotations, the description still covers what the tool returns at a category level (outage/pressure/drought announcements) and when to call it. The remaining gap is default/filter behavior when county and district are omitted, which is minor for a 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?

Schema description coverage is 100% – both county and district are documented with examples in the schema itself. The description adds no format, matching, or fallback guidance beyond that, 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?

States a specific verb (查詢/query) and a precisely scoped resource: Taiwan water outage and pressure-reduction announcements from both 台水 and 北水, plus drought warnings. This clearly separates it from siblings like get_power_outages (power vs water) and the benefit/price tools without needing to open any schema.

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?

Gives concrete trigger examples ('我家附近會停水嗎', '鳳山停水') that map directly to real user phrasings, which is strong context for invocation. It stops short of explicit exclusions or naming alternatives (e.g. when to prefer get_power_outages or a drought-specific tool), so it sits at clear-context-but-no-boundaries rather than a full 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the government announcement source, implying authoritative and time-sensitive data, but says nothing about freshness/lag, whether it covers future days, or the response shape. Adequate for a low-risk read lookup but not rich.

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 with zero waste: purpose plus data source first, usage triggers second. Nothing is padded and the most important information is front-loaded.

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 single optional-parameter read tool with no output schema, the definition is nearly sufficient. A brief note on what the result distinguishes (work vs. school closures, county coverage) would close the remaining 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 100% and the county parameter's meaning (e.g. 高雄市; 不填為全台) is fully documented in the schema. The description adds no format or scope detail beyond what the schema already states, 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?

States a specific verb (查詢) and resource (台灣各縣市停班停課) with the authoritative data source (行政院人事行政總處公告) named. An agent can distinguish this from siblings like get_holidays or is_holiday without opening any schema.

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?

Gives explicit trigger conditions: use during typhoons/natural disasters and when the user asks questions like 「明天要上班嗎」 or 「高雄停班停課」. Clear context is provided, though no alternative tool or when-not condition is named.

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 bears the full burden. It usefully discloses that adjusted holidays and makeup workdays are included, which is a real behavioral detail. However, it omits the return format, data source, and an explicit read-only assurance (though 查詢 implies a read).

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 tight sentence, front-loaded with the purpose and its special-case scope. No filler or 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?

For a simple read-only lookup with one fully documented required parameter, the description covers purpose and edge cases. The only notable gap is the lack of any return-value statement, which is a minor omission given there is no 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 100% for the single date parameter, and the description adds no syntax or format meaning beyond what the schema already provides. Baseline 3 is appropriate 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?

Specific verb (查詢) and resource (台灣某一天是否放假), with scope explicitly including 補假/補班. The name is_holiday distinguishes it from the sibling get_holidays, but the description never names that alternative, so it stops short of a 5.

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 guidance and no mention of when to prefer this over get_holidays. Usage is only implied by the function statement itself.

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