Formosa MCP — Taiwan data

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

No annotations are supplied, so the description carries the full disclosure burden. It does contribute one real behavioural fact beyond the name: the service only covers three specific municipalities, which is a hard coverage limit an agent cannot get from the schema. However it says nothing about whether results are ordered by collection time, how multiple filters combine, or what happens for an unsupported city.

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 sentence with no filler, and the scope (the three cities) is front-loaded as the key constraint. 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 five-parameter lookup tool with no annotations and no output schema, one sentence is thin. Nothing indicates what a result looks like (collection point, time, weekday), how `time` and `weekday` interact (is weekday defaulted to today?), or how `district` and `keyword` overlap despite the schema noting district may be omitted. The complete schema prevents total failure, but the description does not prepare the agent for the tool's behaviour.

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, and the description earns above that by effectively enumerating the valid values for the free-text `city` parameter — the three supported municipalities — which the schema cannot express because `city` is an unconstrained string with no enum. It adds nothing about the other four parameters, but they are already fully documented 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 (查詢…垃圾車定點收運時刻) and scopes it to three named cities, so an agent immediately knows this is a garbage-truck schedule lookup. It is clearly distinct from every sibling (invoice, outage, stock, TRA/THSR timetable tools). It stops short of 5 because it never mentions the filtering capabilities (time, keyword, weekday, district) that define the tool's actual behaviour.

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 or when-not-to-use guidance, and no alternatives are named. The only implicit guidance is the coverage boundary: it serves only 新北市, 臺北市 and 臺中市, which hints that other cities are out of scope but never says so explicitly or states what happens then. An agent must infer everything about selecting this tool from the name alone.

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 disclosure burden and does add real behavior: the default period scope (latest + still-claimable previous) and the digit-length rule that restricts short numbers to sixth prize. It does not disclose what a result looks like (match/no-match, which prize tier) or whether the operation is purely a read, leaving meaningful gaps for a checker 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?

Two compact clauses, front-loaded with the core action, and the default-period caveat follows immediately. The bilingual duplication doubles the length but adds no wasted reasoning; it is efficient for its content.

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?

No output schema exists, yet the description says nothing about what is returned beyond the implicit notion of a prize check, and the period string format is unspecified. Given the low complexity of a two-parameter lookup, this is close to adequate but the missing return-shape and period-format details are real omissions.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It adds genuine meaning for 'number' (3–7 digits limits matching to sixth prize) and for 'period' (omitted means latest plus previous claimable period), but gives no format or syntax for the period value (e.g., 11306 vs 2025-06) and leaves the 8-digit full-number case implicit.

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: checking a Taiwan invoice (統一發票對獎) against winning numbers. It is distinguishable from sibling invoice_get_winning_numbers by the fact that it checks a user-supplied number rather than retrieving the numbers, though it never names that sibling 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 gives useful conditional guidance: when no period is specified it checks the latest period plus the previous one that is still claimable, and it warns that 3–7 digit numbers only match sixth prizes. There is no explicit when-not guidance or pointer to invoice_get_winning_numbers for retrieving the prize tables, so routing is implied 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 are supplied, so the description carries the full disclosure burden. It does say what is returned (winning numbers and the claim period), but says nothing about the response shape, the accepted period format, or whether the data lags the official draw announcement.

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 short sentences, resource first and the default-behavior rule second, so nothing is buried. The bilingual duplication is mildly redundant but is the only real padding.

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 trivial one-parameter read tool with no output schema, the description covers what it fetches and the default behavior. The missing piece is the period string format, which an agent cannot infer from either the schema or the text.

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

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

Schema description coverage is 0%, so the bare string type gives an agent nothing. The description partially compensates by explaining that the single parameter can be omitted to get the latest draw, but it never specifies the expected format (e.g. '11301' vs '2024-01').

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 in both Chinese and English: query Taiwan uniform-invoice winning numbers plus the prize-claim period. That is clearly distinct from sibling invoice_check, which implies verifying one specific invoice, though the description never names that sibling 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?

"Omit period for the latest draw" gives one concrete usage rule for the optional parameter, which is genuinely actionable. However, there is no guidance on when to prefer this over invoice_check, and no statement of what period values are valid.

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 supplied, the description carries the full burden. It does disclose one genuinely useful behavioral trait: coverage is limited to pre-announced planned outages, so absence of results does not mean no outage. It says nothing about data freshness, source authority, result volume, or whether the default date window can return very large result sets beyond what the schema notes.

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 short clauses, front-loaded with the core purpose and the most important caveat. The trailing English sentence 'Planned water/power outages only.' partially restates the Chinese but serves as a compact locale-independent summary; low waste overall.

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 six-parameter read tool with full schema documentation and no output schema, the description covers purpose and the critical coverage limitation. The main residual gap is that nothing describes what a returned notice contains or how results are ordered, though with a rich schema this is a minor omission.

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% — every parameter including city, type enum, keyword, district, and both dates with defaults and the 31-day cap is documented in the schema itself. The description adds no parameter meaning beyond that, 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 (查詢計畫性停水、停電公告 / planned water and power outage notices) and immediately bounds the domain to planned events. Sibling tools are in unrelated domains (garbage, invoices, stocks, transit), so no sibling disambiguation is needed, but the description does distinguish planned from emergency outages, which is the meaningful axis here.

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 what this tool will NOT cover — emergency repairs, accidents, typhoon-caused outages are never announced in advance — which implicitly defines when to use it (planned-outage lookups) and when results will be empty by design. However, it names no alternative tool or data source for the excluded cases, and gives no explicit 'use this when' phrasing.

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 supplied, so the description carries the full burden. It implies a read-only query, but it never defines what '近期' (upcoming) means, such as the look-ahead window, whether the result is paginated or capped, or what happens for delisted or invalid codes. For a tool with no annotation coverage, this leaves real behavioral gaps.

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?

Both sentences are short and front-load the resource description before the parameter behavior. The Chinese and English versions are near-verbatim duplicates, which is redundant for a monolingual agent but serves internationalization. There is no filler beyond that duplication.

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?

This is a simple, one-optional-parameter read tool with no output schema, so the description is close to sufficient. The main gap is that 'upcoming' is never quantified, so an agent cannot tell what date horizon the returned calendar covers. That is a meaningful omission given there is no output schema to clarify 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 coverage is 0%, so the description must explain the single parameter, and it does: the query is optional and accepts either a stock code or a stock name. That is the key semantic the bare string-typed schema lacks. The description omits format details, such as whether codes must be numeric or zero-padded, but the core meaning is conveyed.

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 gives a specific verb and resource: querying upcoming TWSE/TPEx ex-dividend and ex-right dates, optionally for a named or coded stock. It clearly separates this from quote-style siblings like stock_quote, though it never names an alternative tool. The scope (listed/OTC companies, upcoming dates) is 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?

The phrase 'optional code or name' implies the tool can be called with no arguments to get a broad schedule and with one argument to narrow the result, which is useful implicit guidance. There is no explicit when-to-use framing, no advice on choosing between a code and a name, and no direction relative to stock_quote or other siblings.

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 usefully discloses that data is end-of-day rather than real-time and that it covers TWSE/TPEx markets, which prevents a mistimed query. It omits what happens on an unknown ticker, whether the response is a single record or a list, and any rate or availability limits.

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 short bilingual sentences, each front-loaded with the resource and the key caveat ('非即時' / 'not real-time'). The duplication costs some tokens but keeps the definition readable for either language.

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 read tool with no output schema, the description covers purpose, market scope, and non-real-time behavior, which is close to sufficient. It falls short on return shape, invalid-input behavior, and how it differs from the overlapping stock_dividends sibling.

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

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

Schema coverage is 0%, so the description must compensate; saying the single query accepts a ticker code or a name adds real meaning beyond the bare 'query' string. It still lacks format examples (e.g., numeric code vs Chinese name) and doesn't state whether partial matches are accepted.

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 resource (TWSE/TPEx end-of-day quote) and what it returns (price, PE ratio, dividend yield) by code or name. It does not, however, distinguish this tool from the sibling stock_dividends, which overlaps on the dividend-yield 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?

'by code or name' and 'not real-time' imply usage context, but there is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as tra_live for real-time data or stock_dividends for dividend detail.

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, and it does add real behavioral context: date defaults to Taipei's current date, station inputs may be names or codes, and the 24:00–29:59 convention marks post-midnight departures of the operating day. It says nothing about what the response contains (all trains that day? a windowed slice?), ordering, or result size, which is a notable gap for a read with no output schema.

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?

Highly compressed but front-loaded: the core action and resource come first, then the parameter conventions in short semicolon clauses. The trailing English sentence is a bilingual echo rather than new content, but it costs little and the whole definition stays under two lines while covering every parameter.

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 lookup with no annotations and no output schema, the description covers the call side adequately — inputs, defaults, and the unusual time convention are all addressed. What is missing is return-side context: whether the result is a full-day train list, whether times/train numbers/fares are included, and how a partial-day `time` filters the list.

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 25% (just `time`), so the description must compensate, and it does: it clarifies that origin/destination accept either station names or codes, that date is optional and defaults to today in Taipei, and that time is HH:mm with the extended-hours convention. These are the semantics the bare schema lacks; only the departure-window meaning of `time` relative to a returned timetable is left implicit.

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: '查高鐵某日起迄站時刻' (query THSR timetable for an origin/destination pair on a date), and the THSR label implicitly separates it from tra_timetable. It does not explicitly name the sibling, so differentiation is left to the agent's knowledge of the rail systems.

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 'THSR OD timetable' but there is no explicit when-to-use or when-not guidance, and no pointer telling the agent to use tra_timetable for conventional rail or tra_live for real-time positions. For an agent choosing among eight scheduling siblings, that omission matters.

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 supplied, so the description carries the full burden. It discloses that data is live/current ('目前位置與誤點', '即時看板') and that the two modes are mutually exclusive, which is genuinely useful. However, it says nothing about data freshness, update frequency, behavior for non-running trains, or error conditions.

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

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

Two tight sentences, front-loading the purpose before the argument constraint, with no filler. The full bilingual duplication is mildly redundant but reasonable for a bilingual 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?

For a two-mode live-query tool with no output schema and no annotations, the description sketches what each mode returns (position/delay vs board) but not the shape or fields of the response. An agent can select the tool but has limited expectations about returned data.

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

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

Schema description coverage is 0%, so the description must compensate, and it does add the critical mutual-exclusivity rule ('恰填一項') that the schema does not express. It still omits format expectations: whether train_no is numeric or with a suffix, and whether station takes a Chinese name, English name, or station code.

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 in both languages: querying the current position and delay of a TRA train, or a station's live board. That implicitly separates it from the timetable sibling (static schedule vs live status), though it never names tra_timetable 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 constraint 'provide exactly one argument' implies two distinct usage modes (train lookup vs station board), but there is no explicit when-to-use guidance or a named alternative such as tra_timetable for schedule queries. The agent must infer which mode applies from the parameter it supplies.

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 at all, the description carries the full behavioral burden. It does disclose non-obvious behavior: the date default is Taipei-local today, and times from 24:00–29:59 denote the early hours of the day after the operating day — a genuinely valuable quirk. It says nothing about read-only nature, rate limits, or result ordering/volume, which leaves meaningful gaps for a schedule-query 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?

Two compact sentences with the core action first, followed by the parameter conventions, plus a short English gloss. Every clause carries information — station format, date default, time format, and the 24:00–29:59 rule — 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?

For a four-parameter read tool with no annotations and no output schema, the description covers the inputs, the default behavior, and the unusual time notation, and '時刻與車種' hints at the returned content. The remaining gap is that the shape of the result (list of departures, per-train fields) is not described at all, which matters since no output schema exists.

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 25%, so the description must compensate, and it largely does: it clarifies that origin/destination accept either station names or codes, explains the date default, and restates the HH:mm plus extended-hour convention for time. All four parameters get some semantic treatment, though it does not say whether origin and destination are symmetric or how ambiguity in station names is resolved.

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: query TRA (臺鐵) timetable between an origin and destination station on a given date, returning times and train types. 'TRA OD timetable with train types' reinforces the scope and implicitly separates it from the sibling thsr_timetable (high-speed rail) and tra_live (real-time). It does not explicitly name those siblings, so differentiation is inferred rather than stated.

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?

Useful operating context is given: stations may be supplied as names or codes, and the date defaults to 'Taipei today' if omitted. However, there is no explicit when-to-use vs. when-not guidance, and no pointer telling the agent to prefer tra_live for real-time information or thsr_timetable for high-speed rail. The agent must infer the boundary from the tool name alone.

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