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

Annotations already mark it read-only, open-world, and idempotent, but the description adds substantial context: prize rules are implemented only for listed games, bingo returns null won, publication is not real time, prizes_pending has a specific meaning, and every result includes ad-bearing links. It also says never to fill in numbers the API does not have, which is important behavioral guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and default behavior, then moves through returns, formats, timing caveats, and source notes. It is long and dense for a single paragraph, and the playsport539 ad disclosure is less relevant to invocation, so it is not maximally concise.

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 still enumerates key return fields such as matched numbers, prize tier, winning condition, per-ticket amount, won null, prizes_pending, and more links. It also explains data freshness limits, which is enough for an agent to call and interpret results correctly.

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%, but the description adds essential per-game semantics for numbers and second_zone that the schema does not fully capture, including number ranges, counts, play-type meaning for 39m/49m, and automatic special-number matching. It also explains the period default.

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 opening sentence names the specific action (check a ticket), the resource (official draw), and the default scope (newest draw unless period is passed). It also states the return content, which clearly separates it from draw-retrieval siblings like latest_draw and get_draw.

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 default draw and how to target another draw via period, plus one ticket line per call and per-game ticket formats. It does not explicitly name sibling alternatives or when not to use this tool, so it is clear but not fully routing.

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, idempotent, and openWorld, but the description adds substantial behavior: official API source, non-real-time publication windows, the prizes_pending meaning, a rule never to invent missing numbers, and a disclosure that every result includes ad-bearing links. This goes well beyond what annotations provide.

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 core schedule information is front-loaded, which is good. But the description is a single dense run-on paragraph with heavy parenthetical nesting and bilingual duplication, so it is less scannable and more verbose than necessary.

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 must carry return-value context, and it does explain the schedule content, next draw date, notices, publication timing, prizes_pending behavior, and the more links. It does not fully specify the response shape, but it covers the operational caveats an agent needs.

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 schema already lists all game ids and Chinese names, so the baseline is 3. The description adds domain context by mapping game names to draw days and times, but it does not add syntax or format guidance for the single game parameter beyond the schema.

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

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

The description states a specific resource, draw schedule, and enumerates exactly what it returns: draw days/times, the next draw date, schedule notices, and publication timing. It is clearly not a results or stats tool, but it never names or distinguishes itself from siblings like latest_draw or list_draws.

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 important usage context that data is not real time and that before 21:30 the day's draw is normally missing, which helps an agent interpret results. However, it gives no explicit when-to-use/when-not-to-use guidance relative to the sibling tools, and no alternative 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?

Annotations already mark it read-only, idempotent, and open-world, but the description adds substantial behavioral context: official API source, publication times, the possibility of a missing prize table, the meaning of prizes_pending, and the warning never to fill in unavailable numbers. This is exactly the kind of context annotations cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core lookup behavior and then adds important caveats in a logical order. It is long, but most sentences carry operational value; the parenthetical Chinese ad disclosure and final link note are useful but make the text slightly 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?

With no output schema, the description still explains that results match latest_draw's fields and includes a `more` link field. It covers timing, missing data, pending prizes, error behavior, and official-source caveats, which is sufficient for an agent to invoke this tool correctly.

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?

Even though schema coverage is 100%, the description adds meaning beyond the schema: dates are Taiwan time, period is required for bingo due to multiple daily draws, and a date alone can be ambiguous. It also explains that missing draws produce an error listing the game's draw days.

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: retrieving one official draw by period number or date. It distinguishes its lookup modes and explicitly references latest_draw as the source of comparable fields, so an agent can identify it 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?

It gives clear selection guidance for date versus period, including the important rule that bingo requires a period because 203 draws occur per day. It also explains the no-draw error behavior. It does not explicitly contrast itself with latest_draw or list_draws, which keeps it from a 5.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: freshness lag, the meaning of prizes_pending ('that does not mean nobody won'), a hard rule never to fabricate missing numbers, precedence of official announcements, and disclosure that the `more` links point to an ad-bearing third-party site. That is unusually rich behavioral context for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Payload contents are front-loaded in the first sentence, followed by source, timing caveats, and the ad disclosure in a logical order. It runs long as a single dense paragraph and repeats the advertising disclosure bilingually, which is slightly redundant but defensible for a Chinese-language audience.

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 has to describe return values, and it does: field-by-field payload, the `more` links, and the prizes_pending edge case. Combined with the freshness timeline, an agent has everything needed to call it and interpret the result correctly.

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 game parameter already lists every accepted id, Chinese name, and the retired games with their history end date. The description adds no further meaning about the parameter, 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+resource ('Latest official draw of a Taiwan Lottery game') and enumerates exactly what comes back: period, date, winning numbers in two orders, special/second-zone number, star-lottery digits, super number, and the prize table. The word 'Latest' plus the fixed enumerated payload separates it cleanly from get_draw (which an agent would expect to take a period argument) and list_draws.

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 operational context: the official site publishes numbers at 21:30 and prizes at 22:00 Taiwan time, so before 21:30 the draw is normally missing and before 22:00 the prize table may be missing. It does not explicitly say 'use get_draw instead when you need a historical period', but the time-window guidance is clear and actionable.

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?

Goes well beyond the readOnly/idempotent annotations: states the upstream source, the 21:30/22:00 Taiwan-time publication windows, that prizes_pending=true means no prize table rather than no winner, an explicit 'never fabricate missing numbers' rule, and that every result contains ad-bearing links. This is exactly the operational context annotations cannot carry.

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 high-value operational facts are front-loaded, but the ad disclosure is duplicated in English and again in a Chinese parenthetical, and the API-scheduling explanation runs on for two sentences. It is informative but noticeably over-written for the payload it delivers.

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 correctly compensates by documenting the `more` field, the prizes_pending flag, and the timing conditions under which results will be incomplete. An agent has everything needed to call it and to interpret sparse or pending results.

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 game ids, month format, last_n range/default and the bingo-only date are already documented. The description restates the same formats and the at-most-one-of constraint rather than adding new syntax or edge-case meaning, 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?

Opens with a specific verb+resource ('Official draws of one game') and immediately bounds the scope to a month or the newest N draws. It also names get_draw as the tool for a single draw's prizes, so an agent can separate list-level from draw-level retrieval without opening a 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 conditional routing: game-specific mode selection ('For 賓果賓果 use date or last_n'), and redirects to get_draw when prize tables are needed. It does not address the sibling latest_draw or draw_schedule, so an agent must infer whether last_n=1 should instead be a latest_draw 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 only cover read-only/idempotent/open-world, but the description adds substantial operational context: data provenance (api.taiwanlottery.com), a non-real-time window (21:30 numbers, 22:00 prizes), the warning that a missing prize table means prizes_pending=true rather than no winner, and the ad-bearing `more` links. These are exactly the caveats an agent needs beyond the structured hints.

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 front-loaded and the independence disclaimer is well placed, but the text carries redundancy (the ads disclosure is repeated in English and Chinese) and includes prize-table/prizes_pending detail that reads as off-topic for a frequency-count tool with no output schema. Roughly a third of the text could be trimmed without losing agent-relevant meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only statistics tool with no output schema, the description covers what is returned (counts, gaps, hot/cold), per-game counting rules, data source, and freshness limits. The only oddity is the prize-table discussion, which does not belong to this tool's output and may briefly mislead about what fields to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining how counting differs per game — 大樂透 special numbers and 威力彩 second-zone numbers counted separately, 3星彩/4星彩 digits counted overall and per position. It restates last_n 1-200/default 30, which is redundant with the schema but harmless.

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 precise verb+resource statement ('Historical frequency of each number over the newest N official draws') and enumerates the exact outputs: count per number, draws since last seen, and most/least frequent. This is clearly distinguishable from siblings like latest_draw or get_draw, which return individual draws rather than aggregate frequency statistics.

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 clear usage context ('last_n 1-200, default 30') and a strong constraint on how to present results ('do not present these numbers as picks'), which is genuine guidance rather than mere description. It stops short of naming an alternative sibling or stating when to prefer get_draw/list_draws instead, so it is not a full when/when-not/alternatives treatment.

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