Taiwan finance open data: ETF, funds, TAIEX, sentiment, business climate, FX. Free & read-only.
國發會景氣燈號：最新月燈號/綜合分數/9 項構成指標逐項檢查值與分數/下期發布日（官方預告）。NDC business climate signal with all 9 components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does disclose the source (NDC/國發會), the nine-component structure, and that the next release date is officially scheduled. However, it does not mention update latency, whether historical months are available, or how the signal values are formatted, leaving partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with only two short sentences covering the essential content in both Chinese and English. It front-loads the core purpose and lists all major return items without 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 zero-parameter tool with no output schema, the description gives a solid inventory of the returned data: light signal, score, 9 components, and next release date. It could be slightly stronger with interpretation guidance or update cadence, but it is largely complete for invocation purposes.
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 has zero parameters, so there are no parameter semantics to clarify. The description still adds value by enumerating the returned data fields, satisfying the baseline expected for a parameterless tool.
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 identifies the resource as the NDC business climate signal and enumerates the exact contents: latest month's light signal, composite score, 9 component indicators, and next release date. It is distinct from broader siblings like market_sentiment, though it lacks an explicit imperative verb such as 'Retrieve' or 'Lists'.
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 guidance is given on when to use this tool versus siblings like market_sentiment or taiwan_market_overview. The intended use is implied by the tool's domain, but there are no explicit conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出本站「資料形狀 × 資料集」登錄表：有哪些 point（單值）／series（時間序列）／table（表格）／query（條件篩選＋群體聚合）資料集，各自的單位、識別碼種類、來源與深連結；query 母體另附可用欄位、運算子與可排序鍵。先呼叫本工具，即可組合出後續查詢。Catalog of datasets by shape (point/series/table/query) — call this first to compose queries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does this well by listing what the catalog returns: dataset shapes, units, identifier types, sources, deep links, and query-specific fields, operators, and sort keys. It does not mention edge cases or errors, but for a zero-parameter read-only catalog this is reasonably transparent.
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 main purpose and spends only a few sentences on details. The bilingual text adds length through repetition, but each clause still carries meaningful information and there is 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 zero-parameter discovery tool with no output schema, the description is complete enough: it details the catalog contents and explicitly tells the agent to invoke it first. It does not describe how to consume the returned deep links or identifiers in sibling tools, but the 'compose queries' hint covers the essential workflow.
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 accepts zero parameters, so there is no parameter semantics to explain. The empty input schema and 100% schema coverage mean the description does not need to compensate for undocumented inputs.
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 uses a specific verb ('列出' / 'list') and a specific resource: the registry of datasets by shape (point/series/table/query). It clearly distinguishes this catalog tool from the data_* siblings, since its job is to describe available datasets rather than return data values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'call this first' ('先呼叫本工具') and explains that it is used to compose subsequent queries. This gives a clear context for when to use the tool, though it does not state explicit exclusions or alternative routing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取「一個標的 × 一個欄位 × 一個時點」的單值，如 0050 的折溢價、基金最新淨值、USD/TWD 匯率、景氣對策信號綜合分數。dataset 取自 data_catalog 的 point 清單；回應必附單位、資料日與來源。Single current value for one security and field.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | 標的識別碼，如 0050／T1104Y／USD/TWD；可加前綴消歧義，如 etf:0050、fund:T1104Y | |
| dataset | Yes | 資料集，如 etf.premium／fund.nav／fx.rate（見 data_catalog） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does well by stating that responses always include unit, data date, and source, and it clarifies the dataset source. It does not cover error behavior or disambiguation failures, but for a simple read-only lookup the disclosed response guarantees are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core concept, and every sentence contributes useful information. The Chinese and English summaries reinforce each other without redundancy, and the examples are efficient.
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 tool with no output schema, the description covers the essential context: what the tool returns, where dataset values come from, and representative inputs. It could further clarify when 'id' is optional versus required, but this is a minor gap given the schema already documents the parameter.
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 adds value beyond the schema by giving real-world examples of both 'id' and 'dataset' values (0050, T1104Y, USD/TWD, etf.premium, fund.nav, fx.rate) and explaining that datasets come from data_catalog's point list, which helps the agent construct valid calls.
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 uses a specific verb ('取') and clearly defines the resource as a single value at the intersection of one target, one field, and one point in time. Concrete examples (0050 premium, fund NAV, USD/TWD rate) make the tool's scope unmistakable and naturally distinguish it from series or table queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a single current value is needed. It also tells the agent that 'dataset' must come from the data_catalog point list, which is actionable guidance. However, it does not explicitly name sibling alternatives like data_series or data_query or state when those should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
對一個母體下條件篩出一組標的，並對整組計算聚合統計（count／coverage／min／max／mean／median／sum），如「費用率 0.4% 以下的被動 ETF，其費用率中位數」。where 語法為「欄位 運算子 值」以 and 連接（例 fee<=0.4 and type=passive）。回應必附母體大小 population 與欄位覆蓋率 coverage（有幾檔真的有這個欄位）。注意：績效欄位可用於 where 篩選與聚合統計，但不得作為排序鍵——排序即排名，本站不對個別商品做推薦。Filter a universe and aggregate over the matched set.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 排序鍵，只接受中性鍵 code／name／holders（規模/人氣），不接受績效欄位 | |
| limit | No | sample 回列數，預設 10、上限 20 | |
| where | No | 條件式，如 fee<=0.4 and type=passive；省略＝全母體 | |
| universe | Yes | 母體，如 etf.tw（見 data_catalog） | |
| aggregate | No | 聚合，如 median:fee,count（逗號分隔、最多 4 個） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that responses always include population and coverage, defines coverage semantics, and explicitly prohibits performance fields as sort keys because '排序即排名'. It could also state read-only guarantees or error behavior, but the non-obvious contract is well covered.
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 purpose and a worked example, then moves to syntax, output guarantees, and constraints. The final English sentence is somewhat redundant with the Chinese opening, but the overall structure is efficient and readable.
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?
Given there is no output schema, the description documents the key return fields (population, coverage), the supported aggregate functions, and an important ranking-policy constraint. It is complete enough for typical calls, though the exact response shape for aggregate results is left implicit.
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, but the description adds real value beyond the schema by explaining where syntax ('field operator value' joined by 'and'), the aggregate vocabulary, and the meaning of population/coverage. Some details like limit and universe sourcing are left to the schema, but the added semantics justify a score above baseline.
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 clear action ('Filter a universe and aggregate over the matched set') and enumerates the supported aggregate functions, so an agent can tell this is a grouped-query tool. It does not explicitly distinguish itself from sibling tools like data_point or data_series, which keeps it from 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?
Provides a concrete worked example ('fee<=0.4 and type=passive' with median fee) and explains the where grammar and the sort restriction on performance fields. It gives clear context for when the tool is appropriate, though it does not explicitly describe when to prefer an alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取「一個標的 × 一個欄位 × 一段時間」的時間序列，如 ETF 日收盤、基金淨值歷史。每點只有日期與值；資料缺口會以 gapNote 誠實標示、不靜默補值。Time series for one security and field.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 標的識別碼，如 0050、T1104Y | |
| months | No | 回看月數，預設 12、上限 120 | |
| dataset | Yes | 資料集，如 etf.close／fund.nav（見 data_catalog） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses return shape ('每點只有日期與值') and truthful gap handling ('資料缺口會以 gapNote 誠實標示、不靜默補值'), which is meaningful behavioral information beyond the schema. It omits ordering/pagination/error details, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core usage pattern in the first clause and key output behavior in the second. The trailing English sentence 'Time series for one security and field' is slightly redundant with the Chinese opening, but the overall size is still appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description covers enough: parameters are fully described in the schema, response shape (date/value) and gapNote behavior are stated, and dataset values are linked to data_catalog. The main unresolved context is how this generic series relates to siblings like etf_price_history or fund_nav_history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, months, and dataset, including defaults and limits. The description's '一個標的 × 一個欄位 × 一段時間' maps conceptually to the parameters but adds little parameter-level detail 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?
Description opens with a precise operation: 取「一個標的 × 一個欄位 × 一段時間」的時間序列, naming the action, resource scope, and time dimension. Examples (ETF 日收盤、基金淨值歷史) and '每點只有日期與值' make it easy to distinguish from single-point data_point or multi-column data_table siblings.
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 clearly defines when to use it: any need for a one-security, one-field historical series, with concrete use cases. It does not explicitly name alternatives or state when not to use data_table/data_query/etf_price_history, so it lacks exclusions but still gives strong context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取「一個標的的多列資料」，如 ETF 全成分股與權重、景氣對策信號 9 項構成指標、主要貨幣對一覽。回應含欄位定義（columns）與列（rows），截斷時標 truncated。Multi-row table for one security.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | 標的識別碼；母體級表格（如 fx.pairs）免填 | |
| limit | No | 回列上限，預設與上限皆為 200 | |
| dataset | Yes | 資料集，如 etf.holdings／fx.pairs／market.climate.components（見 data_catalog） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure weight. It explains the response shape (columns and rows) and the truncation flag, which are useful behavioral details beyond the schema. It does not mention side effects or permissions, but this is a read-style table lookup and no destructive behavior is implied.
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 short and front-loaded with the core behavior, followed by response details and a concise English summary. The English sentence somewhat repeats the Chinese opening, but this is minor and the overall structure is efficient.
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?
The description covers the return format and truncation behavior, and the schema covers all parameter meanings, so the tool is callable without missing critical information. It could add a bit more about how to discover valid datasets, but the dataset parameter already references data_catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, limit, and dataset. The description does not add significant parameter semantics beyond examples already present in the schema, so the baseline of 3 is appropriate.
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 the tool fetches multi-row data for one target, with concrete examples like ETF holdings, climate indicator components, and FX pairs. The closing English phrase 'Multi-row table for one security' distinguishes it from single-point or time-series siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples and the 'one security' phrasing give an agent a clear sense of when to use this tool, and the schema points to data_catalog for valid datasets. However, it does not explicitly state when to prefer data_point or data_series instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以代號查台灣上市 ETF：名稱/發行投信/追蹤指數/市價/折溢價/費用率等基本資料。Look up a Taiwan-listed ETF by code (e.g. 0050).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ETF 代號，如 0050、00878 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述清楚列出會回傳的資料欄位，讓 agent 知道查詢結果的內容範圍。但沒有 annotations 提供安全或唯讀資訊，描述也未提及查無代號時的行為、資料更新時間或任何限制，因此行為透明度僅屬中等。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述以單一雙語句完成，前半段直接點出用途，後半段補上英文對照與範例，無冗餘內容。資訊密度高且重點前置，符合簡潔結構標準。
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?
工具只有一個已完整文件化的參數，無巢狀結構，複雜度低。描述已列出主要回傳欄位，足以讓 agent 判斷查詢結果類型；雖無 output schema，但對於簡單查詢工具而言已算完整。缺少的 sibling 分流說明在 usage_guidelines 已扣分，此處不重複懲罰。
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 已 100% 說明 code 參數，且提供 0050、00878 範例。描述中的「e.g. 0050」與 schema 重複，僅略為強化格式概念，未在 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?
描述包含具體動詞「查」、明確資源「台灣上市 ETF」及代號查詢方式，並列出回傳欄位如名稱、發行投信、追蹤指數、市價、折溢價、費用率。與 sibling 如 etf_price_history、fund_lookup 能清楚區分，因為它專注於 ETF 基本資料而非歷史價格或基金資料。
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?
描述暗示此工具用於以代號查詢 ETF 基本資料，但未明確說明何時不該使用，也未提到應改用 etf_price_history 或其他 sibling。使用情境是隱含的，而非明示的排除或替代指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取 ETF 每日收盤價序列（預設近 12 個月、可調 months 1-120）。Daily close history for a Taiwan ETF.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| months | No | 回看月數，預設 12、上限 120 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default lookback (近12個月), adjustable months range (1-120), and that the data is daily close prices. However, it duplicates the schema's months description and does not disclose output format, ordering, timezone, or error behavior — though for a simple read-only historical fetch, this is partially sufficient.
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 two short clauses with no filler. It front-loads the action ('取') and object ('ETF 每日收盤價序列'), and the English sentence adds the Taiwan market context without repeating the full Chinese text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain what the returned series looks like, but it only says '每日收盤價序列' (daily close price series). It does not mention the structure (e.g., array of date/close pairs), currency, adjusted vs raw prices, or how to obtain a valid ETF code. This leaves important gaps for an agent to call it correctly in an automated context.
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%: 'months' is described in the schema, while 'code' is not. The description adds domain context that the code refers to a Taiwan ETF and that months controls lookback (1-120), partially compensating for the undocumented 'code' parameter. It does not specify the code format or expected value type, so the compensation is incomplete.
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 uses a specific verb ('取' / fetch) with a specific resource ('ETF 每日收盤價序列' / daily closing price series), and specifies the market ('Taiwan ETF'). This distinguishes it from siblings like fund_nav_history (fund NAV) and etf_lookup (ETF metadata), even without naming them.
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 intended use case is implied by the phrase 'ETF 每日收盤價序列' and 'Daily close history for a Taiwan ETF,' so an agent can infer when to use it. However, there is no explicit guidance about alternatives or when not to use it, which leaves some ambiguity given the many data-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以 search 回傳的 id 取該筆的完整內容（id／title／text／url／metadata）。A string which is a unique identifier for the search document.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A string which is a unique identifier for the search document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description has to carry the behavioral burden. It discloses the output fields, and the verb '取' implies a read-only operation, but it does not explicitly state that it has no side effects or describe error behavior for invalid ids. This is adequate 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?
The first sentence is front-loaded and informative, but the second sentence is a verbatim copy of the schema's parameter description, adding no new information. This redundancy is wasteful, so it cannot earn a higher score despite the overall brevity.
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?
Given there is no output schema, the description appropriately enumerates the return fields. It also specifies the input source. It omits edge-case behavior such as missing ids, but for a simple single-parameter fetch tool this is not a critical gap. The lack of annotations makes some safety context implicit rather than explicit.
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 schema already documents the id parameter with 100% coverage, so baseline is 3. The description adds meaning by clarifying that the id originates from a search result and by associating it with the complete content fields. The second sentence, however, redundantly repeats the schema description, slightly reducing the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '取得' (retrieve) with a clear resource: the full content of a record identified by the id returned from search. It lists the returned fields (id/title/text/url/metadata), which distinguishes this from sibling search and data lookup tools.
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 explicitly states the id must come from a prior search call ('以 search 回傳的 id'), establishing the intended workflow. It does not explicitly name alternatives or exclusions, but the search-then-fetch context is clear enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以代號或名稱關鍵字查台灣可銷售基金（境內投信/境外/期信）：最新淨值/淨值日/幣別/類型/總代理/今年以來報酬。Search Taiwan-distributed funds by code or name keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 基金代號（如 T1104Y）或名稱關鍵字（如 摩根 科技） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains what the tool returns (latest NAV, NAV date, currency, type, distributor, YTD return) which is useful. However, it doesn't disclose behaviors like whether the search supports partial matching, case sensitivity, or whether it only returns the latest snapshot vs. historical series. It also doesn't mention any limitations (e.g., only Taiwan-distributed funds). For a read-only search tool, this is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one bilingual sentence that states the search input and the output fields. It front-loads the key purpose and includes examples for the parameter. Every sentence earns its place, and the bilingual structure is useful for the target domain, no waste.
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-parameter search tool with no output schema and no annotations, the description covers the essential: what it searches, what it returns, and what the input looks like. It could mention whether the result is a single fund or multiple funds, but given the simplicity and the explicit output fields, it is reasonably complete. Sibling differentiation is also handled by naming the tool 'fund_lookup' vs. 'etf_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%, so the single parameter 'query' is fully described with examples (T1104Y, 摩根 科技). The description adds a bit by stating it accepts code or name keyword, but that mostly mirrors the JSON schema. Baseline 3 is appropriate because the schema already gives clear semantics.
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 the tool's function: searching Taiwan-distributed mutual funds by code or name keyword, and lists the specific information fields returned (latest NAV, NAV date, currency, type, general agent, YTD return). This distinguishes it from siblings like etf_lookup, which focuses on ETFs, and other market data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies the tool's use case: searching by fund code or name keyword. This is differentiated from sibling tools like etf_lookup (for ETFs) and fund_nav_history (for historical NAV), though it doesn't explicitly say 'use this instead of X'. Given the sibling list, the scope is clear enough, and the first sentence provides a direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
主要貨幣即期匯率（多源交叉：ECB/台銀）含當日與近 1 週/1 月/3 月變化；可指定 pair（如 USD/TWD）。Spot FX rates with multi-period changes.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | 貨幣對，如 USD/TWD；省略＝全部 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses meaningful behavior: multi-source cross-referencing (ECB/台銀) and output containing same-day plus 1-week/1-month/3-month changes. It does not detail update frequency or exact output shape, but these are non-critical for a read-only spot-rate 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?
The description is short, front-loaded with the core purpose, and packs sources and time periods efficiently. The English sentence mostly repeats the Chinese content, creating minor redundancy, but it does not waste much space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with full schema coverage, the description is reasonably complete: it tells the agent what the tool returns and that a pair can be specified. The lack of an output schema is partly compensated by describing the included time-period changes. Missing guidance on sibling selection is the main 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 description coverage is 100%, so the pair parameter is already documented in the schema. The description adds a concrete example (USD/TWD) but no additional semantic detail beyond what the schema already states, so the baseline of 3 is appropriate.
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 identifies the resource as spot FX rates for major currencies, with multi-period changes and optional pair specification. It does not use a strong verb like 'retrieve' or 'get', and it does not explicitly contrast itself with sibling tools, so it falls just 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?
The intended use is implied by 'Spot FX rates' and the optional pair parameter, so an agent can infer this is for currency rate lookups. However, it does not state when to prefer this over sibling tools such as data_point, fetch, or market_sentiment, nor does it give any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
台股情緒綜合分數（本站自製中性參考、含分項）與美股 CNN Fear & Greed（含 CNN 原始時點）。Taiwan + US (CNN F&G) market sentiment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It does disclose useful traits: the Taiwan score is site-compiled and meant as a neutral reference, includes sub-items, and the CNN portion includes its original timestamp. It does not, however, explain update cadence, data recency, derivation methodology, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with specifics. The English closing sentence largely restates the Chinese sentence, adding mild redundancy, but overall the structure is efficient and scannable.
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 zero-parameter tool this is reasonably complete, listing both market sentiment components and noting sub-items and timestamps. However, there is no mention of output shape or update behavior, and the absence of annotations means the description alone must cover these expectations; it only partially does.
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 has zero parameters and the schema is an empty object with 100% coverage, so there is nothing for the description to add. Baseline 4 applies for parameter-free tools.
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 identifies the resource: Taiwan stock market sentiment composite score (site-made neutral reference with sub-items) and US CNN Fear & Greed with original timestamps. It adds concrete scope beyond the title and can be distinguished from siblings like taiwan_market_overview and business_climate by its explicit sentiment focus.
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 usage context is implied by the content described—an agent can infer this tool is for sentiment data rather than fundamentals or market overviews. However, there is no explicit guidance on when to prefer this tool over siblings, nor any exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以一段查詢字串搜尋本站的 ETF、台股、基金與資料集，回傳可引用的清單（id／title／url）。id 可交給 fetch 取完整內容。A single query string; returns citable results for Taiwan ETFs, stocks, funds and datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A single query string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries much of the behavioral burden. It usefully discloses that results are citable, include id/title/url, and that the id can be passed to fetch. It does not mention potential result limits, pagination, ordering, or any rate/access considerations, leaving some behavioral uncertainty for a search operation.
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 short, front-loaded with the core action, and conveys the important return format and fetch linkage in two sentences. The bilingual repetition is slightly redundant but not wasteful, and every key fact an agent needs fits in a compact space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, this description covers the essential invocation context: what to search, what categories are included, what the result looks like, and how to proceed with fetch. It omits details like maximum result count or pagination, but the tool is simple enough that the missing pieces are not critical.
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 single query parameter already has a clear description: 'A single query string.' The tool description repeats this phrasing and adds the context that the query searches across the named asset/dataset categories, but does not add deeper semantics such as query syntax, supported operators, or length constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a query string searches the site's ETFs, Taiwan stocks, funds, and datasets, returning a citable list with id/title/url. It also explains the follow-up relationship with fetch, which helps distinguish it from specialized lookup siblings such as etf_lookup and fund_lookup.
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 intended use is implied: use search when you have a free-text query spanning ETFs, stocks, funds, or datasets, and use the returned id with fetch for full content. However, it does not explicitly state when to prefer search over the sibling lookup tools or what conditions would make another tool more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
台灣加權指數（TAIEX）最新官方收盤、市場廣度（漲跌家數）、台股情緒分數、台指選擇權 Put/Call 比一次取得。Taiwan market snapshot: TAIEX close, breadth, sentiment, PCR.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does disclose that the close is the latest official TAIEX close and that the results are aggregated into one snapshot, but it does not describe output format, staleness, or any special behavior.
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 two concise sentences, front-loading the key contents in Chinese and providing an English summary. Every part is useful and there is 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 zero-parameter snapshot tool, the description lists the main return fields and is sufficient to invoke the tool correctly. It could be slightly more complete by noting the output structure, but the absence of parameters and output schema makes the current text largely adequate.
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 has zero parameters, so the baseline is 4. There is no parameter documentation needed, and the description correctly focuses on what the returned snapshot contains.
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 identifies a specific resource—a Taiwan market snapshot—and explicitly lists its components: TAIEX close, breadth, sentiment, and Put/Call ratio. This composite scope makes it clearly distinguishable from siblings like market_sentiment or fx_rates.
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 guidance on when to use this tool versus alternatives such as market_sentiment or data_query. The description implies it is for a broad market overview, but it never states when to prefer it over a single-indicator sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Taiwan Stock Exchange (TWSE) open data as MCP tools: stock quotes, ETF data, 140+ public datasets.
Taiwan stock market data (TWMD): official-source, point-in-time-safe datasets via read-only tools.
Open financial reference data: companies with LEI/ISIN/FIGI, markets, funds, graph, live series.
Twelve Data: stocks/ETF/forex/crypto time series, quotes, dividends, splits, earnings.
Add one secure layer between your agents and this server.
Most tools have clear boundaries, but there is notable overlap between data_series and etf_price_history/fund_nav_history, since all three can provide time-series data. market_sentiment and taiwan_market_overview also both expose Taiwan sentiment, creating potential selection ambiguity.
The data_* tools follow a clear prefix pattern, but the rest mix noun-style names (fx_rates, market_sentiment), object-action names (etf_lookup, fund_lookup), and generic verbs (search, fetch). The names are readable and understandable, but the overall convention is inconsistent.
At 15 tools, the count is at the upper edge of the ideal range and mostly reasonable for a Taiwan finance data server. However, several domain-specific wrappers duplicate capabilities already available through the generic data_* tools, so the set feels slightly heavier than necessary.
The generic data catalog plus data_point/data_query/data_series/data_table provides broad coverage for read-only financial data, and the domain tools cover ETFs, funds, FX, market overview, sentiment, and climate indicators. Minor gaps remain, such as no explicit Taiwan stock-specific lookup or price history tool, but the search and generic data layers partially compensate.
