data_point取「一個標的 × 一個欄位 × 一個時點」的單值，如 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.
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.