生活即時查詢

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?

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 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.