台股市場總覽
taiwan_market_overview台灣加權指數(TAIEX)最新官方收盤、市場廣度(漲跌家數)、台股情緒分數、台指選擇權 Put/Call 比一次取得。Taiwan market snapshot: TAIEX close, breadth, sentiment, PCR.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
taiwan_market_overview台灣加權指數(TAIEX)最新官方收盤、市場廣度(漲跌家數)、台股情緒分數、台指選擇權 Put/Call 比一次取得。Taiwan market snapshot: TAIEX close, breadth, sentiment, PCR.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds real value beyond them by stating the data is '最新官方收盤' (latest official close), which discloses provenance and currency, and by enumerating the four metrics returned. It says nothing about update cadence, market-calendar gaps, or whether the PCR is a daily or intraday figure.
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 front-loaded Chinese sentence lists the four returned metrics, then the English line mirrors it compactly. Nothing is padded, though the bilingual duplication means the same content appears twice. The dual-language format serves a real purpose for a Taiwan-focused tool, so the repetition is defensible rather than wasteful.
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 must carry the return-value burden, and it does so only at the label level: it names the four metrics but not their units, scale, or format (for example, is the sentiment score 0-100 or -1 to 1?). For a zero-parameter, zero-output-schema tool this is adequate to select and call it, but an agent cannot anticipate the shape of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema forbids additional properties, meaning agents cannot narrow the request by date or metric, which the description implicitly matches by presenting a single fixed snapshot.
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?
A specific verb-plus-resource statement: it returns a Taiwan market snapshot bundling TAIEX official close, breadth (advancers/decliners), a sentiment score, and put/call ratio. An agent can immediately understand what comes back. It loses a point because the sibling market_sentiment appears to overlap with two of the four returned metrics, and the description does not explain why an agent would pick one over the other.
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 '一次取得' (get it all in one call) implies the intended usage: a consolidated one-shot market snapshot instead of chaining data_point/data_series calls for each metric. That framing is only implied. There is no explicit statement of when to use this rather than market_sentiment, no mention of market hours, holidays, or data delay, and no note about what to do if a component is unavailable.
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.