Skip to main content
Glama

Taiwan Market Open Data (Unofficial)

Futures contract snapshot

snapshot.futures
Read-onlyIdempotent

One TAIFEX futures contract for the latest trading day: open, high, low, close, change, volume, settlement and open interest for each contract month (regular and after-hours sessions), a near-month summary, institutional and large-trader positions, and final settlement prices. Accepts codes ("TX", "MTX") or Chinese names; an ambiguous name returns candidates only. Source: TAIFEX OAS; futures only; not live. 一個期貨契約(最新一個交易日)的完整概況:各月份的開高低收、漲跌、成交量、結算價、未平倉(一般與盤後時段)、近月摘要、三大法人部位(指數類期貨)、大額交易人部位與最後結算價。可用代號("TX"、"MTX"、"TMF"、"CDF")或名稱("台指期"、"小台"、"台積電期貨");名稱對到多個契約時只回 candidates,請向使用者確認再用代號重查。只含期貨;選擇權與整體期貨籌碼請用 dataset.search 或 snapshot.market。

Input Schema

NameRequiredDescriptionDefault
contractYes期貨契約代號或名稱,例如 "TX"、"小台"、"台積電期貨"。

Output Schema

NameRequiredDescriptionDefault
dateNo
nameYes
queryYes
quotesNo
sourceYes
caveatsYes
contractYes
candidatesNo
near_monthNo
institutionalNo
large_tradersNo
final_settlementNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedOutput schema / properties / contract / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / contract / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / date / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / date / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: data source (TAIFEX OAS), staleness ('not live', latest trading day), coverage of regular plus after-hours sessions, and the candidate-only response when a name is ambiguous. It does not discuss rate limits or failure modes for unknown codes.

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

Conciseness4/5

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

Front-loaded with the resource and returned fields, then scope limits, then input handling, then alternatives – a sensible order. The main cost is full bilingual duplication, which roughly doubles the length for a single-language reader, though it serves a bilingual user base and no sentence is filler.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, yet the description still names the key fields. Combined with source, freshness, session coverage, ambiguity handling and sibling routing, an agent has everything needed to select and call this tool correctly.

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

Parameters4/5

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 goes beyond the schema by giving additional accepted codes ('TMF', 'CDF') not in the schema example, listing Chinese-name aliases, and specifying the semantic consequence of an ambiguous name (candidates only). That ambiguity behavior is real parameter semantics the schema does not encode.

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

Purpose5/5

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

States a specific verb+resource: one TAIFEX futures contract for the latest trading day, and enumerates the exact contents (OHLC, volume, settlement, open interest by contract month, sessions, near-month summary, institutional and large-trader positions). It explicitly bounds scope with 'futures only; not live', which cleanly separates it from snapshot.market, snapshot.stock and snapshot.etf.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing for out-of-scope needs: '只含期貨;選擇權與整體期貨籌碼請用 dataset.search 或 snapshot.market'. It also defines the ambiguous-name path (return candidates, confirm with the user, re-query by code), which tells the agent how to behave on a failed lookup. It does not explicitly position itself against snapshot.stock/snapshot.etf beyond the word 'futures', so not a full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.