tw-market-data

Read the supply chain

supply_chain_read

Read-onlyIdempotent

供應鏈與同業:產業鏈位置、同業分組、轉投資、外銷訂單 vs 營收。

    ★ 事實整理,不是投資建議、不是預測。輸出帶 `does_not_prove`。
    ★ ⚠️ `company_peer_groups` 無日期欄:指定過去的 `as_of` 時,回的是**現況**分組,
      `pit_notes` 會標「非當時分類」。
    ★ ⚠️ 質化的客戶/供應商關係與分部營收在年報附註,那條來源**尚未建置** ——
      固定列在 `cannot_see`(status=no_loader),不是這次查失敗。
    ★ Args:`ticker`(例如 "2330")、`as_of`(選填)。
    ★ Returns:誠實信封;外銷訂單與營收的背離會 listed in `concerns`。
    ★ PRECONDITIONS:自己取數;requires 一個已識別的 session。
    ★ SIDE EFFECTS:read-only,does not 寫入。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`as_of`	No
`ticker`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A3.9/5.0

Behavior5/5

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

Despite annotations already marking this as read-only and idempotent, the description adds substantial behavioral detail: the as_of gotcha for company_peer_groups (returns current grouping with pit_notes), the unbuilt source causing cannot_see entries with status=no_loader, and the does_not_prove flag. These behaviors are not visible in annotations and directly help an agent interpret results correctly.

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?

The bulleted structure is clean and front-loaded with the core resource definition, followed by warnings, arguments, return envelope, preconditions, and side effects. Each bullet adds distinct information, though the SIDE EFFECTS line duplicates the information already provided by the readOnlyHint annotation.

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

Completeness4/5

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

The description addresses the tool's key complexities and failure modes: the as_of behavior, unbuilt source loader, divergence detection via concerns, and the meaning of does_not_prove, cannot_see, and pit_notes. Combined with the output schema and annotations, an agent has enough to invoke it correctly. Minor gaps remain, such as ticker semantics and as_of format.

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

Parameters3/5

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

With 0% schema description coverage, the description compensates only partially: it gives a ticker example ('2330') and notes as_of is optional. It also explains a subtle behavior of as_of regarding peer group timing. However, it does not explain what ticker represents or the expected date format for as_of, leaving partial ambiguity for both parameters.

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

Purpose4/5

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

The description clearly identifies the resource (supply chain and peer data) and lists specific data dimensions: industry chain position, peer grouping, investments, and export orders vs revenue. It also states it is a fact compilation, not investment advice or prediction. However, it does not explicitly differentiate itself from sibling tools, so the distinction is implicit in the domain rather than named.

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

Usage Guidelines3/5

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

The description provides context about what to expect (not advice, honest envelope, missing source) and states a precondition (requires an identified session), but it never explicitly states when to choose this tool over alternatives. There are no exclusionary conditions or named sibling alternatives, so usage guidance remains implied by the tool's domain.

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

All tw-market-data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

The tools are largely distinct: querying, searching, backtesting, risk reads, alerts, memory, and audit functions each have clear homes. A few adjacent pairs (risk_read vs risk_assess, company_health_check vs positioning_read) could be confused, but the descriptions draw explicit boundaries.

Naming Consistency3/5

There are strong consistent clusters like list_*, get_*, run_*, and memory_*, but the *_read suffix alternates with noun-first names like company_health_check, and bare-verb tools like ask, calendar, chart, and screen break the pattern. The naming is readable but not uniform.

Tool Count2/5

Forty tools is well past the 25+ threshold and makes the surface heavy for an agent to navigate, even though the breadth reflects a genuinely wide platform. Several clusters could plausibly be consolidated without losing capability.

Completeness4/5

The tool surface covers the main lifecycle well: discovery, point-in-time querying, filings search and full text, backtesting, research, risk assessment, alerts, memory, approvals, and provenance verification. Minor gaps exist—no strategy management tools, no memory deletion, no bulk export—but agents can work around them.

Resources

Need Help?