tw-market-data

Query the macro regime

query_regime

Read-onlyIdempotent

The Taiwan business-cycle light (NDC monitoring indicator) as a monthly series.

★ THIS IS A REVISED FIGURE, NOT A POINT-IN-TIME ONE. Every response carries
`revision_basis: as_revised`. Our source holds exactly one row per month — the CURRENT value,
not the value as first published — and it records no publication date.

★ `as_of` IS REFUSED, AND THE REFUSAL IS THE POINT. There is no honest point-in-time answer
here yet. Do NOT work around it by asking for a date range that ends at your as_of: the NDC
publishes a month's light about 27 days AFTER that month ends, so a range ending 2026-03-05
still contains the February light that was not public until late March. That is look-ahead, it
raises no error, and it makes a backtest look better than it was.

★ USE IT FOR CONTEXT, NOT AS A BACKTEST INPUT. Describing what regime the market is in today,
or labelling historical periods for narrative, is fine. Feeding it into a simulated decision
that claims to have been made at the time is not.

Args: optional start/end (YYYY-MM-DD), limit. `as_of` returns a refusal explaining the above.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`end`	No
`as_of`	No
`limit`	No
`start`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing that data is as-revised rather than point-in-time, that `as_of` is refused, that the source has a single current row per month with no publication date, and that using date ranges ending at `as_of` still creates look-ahead. This is exactly the kind of behavioral context an agent needs.

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

Conciseness5/5

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

The description is longer than average, but every bullet earns its place: the revised-data warning, the `as_of` refusal and its rationale, and the explicit backtest-context boundary. The most important caveat is front-loaded, and the structure makes the warnings easy to absorb.

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?

Given the output schema is present, the description does not need to explain return values. It covers the data revision status, the refusal behavior, the look-ahead trap, and the intended use case, making the tool safe and unambiguous to invoke.

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 carries the burden for parameters. It adds crucial meaning for `as_of` and for date-range behavior, but it does not explicitly explain the formats or semantics of `start`, `end`, or `limit`, leaving those to be inferred from their titles and defaults.

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 title and description clearly identify the resource: the Taiwan business-cycle light (NDC monitoring indicator) as a monthly series. It communicates the core function well, though it never explicitly names or contrasts itself with the similarly named sibling `macro_regime_read`, so some differentiation is left implicit.

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?

The description gives explicit usage context: use it for market context, not as a backtest input, and do not work around the `as_of` refusal by date-range tricks. It does not name an alternative tool to use for backtest inputs, so the guidance is clear on when not to use it but less explicit about what to use instead.

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?