Skip to main content
Glama
TeacherLi07

htx-mcp

by TeacherLi07

HTX Wait For Market Event

htx_wait_for_market_event
Read-onlyIdempotent

Wait until market prices or indicators meet declarative conditions or the timeout expires. Set any/all match rules to pause until your target price or indicator threshold is reached, then return compact evidence.

Instructions

Block until bounded declarative market conditions match or the timeout expires.

This safe MCP wait primitive performs read-only calls, executes no caller-supplied code, has a fixed deadline, and returns compact evidence. A future WebSocket market daemon can satisfy the identical contract.

Important: while this call is pending, the agent receives no intermediate market updates and cannot react to them. For an uninterrupted wait, set the outer host yield_time_ms longer than timeout_seconds * 1000 (with response margin) and set the host tool deadline longer still. The MCP result then becomes the sole wake-up source; then re-check market snapshots after every return.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
matchNoWake when any condition matches, or only when all match.any
productNo
conditionsYesDeclarative conditions to wait for. Each condition may override product and instrument, allowing independent markets in one wait. A condition checks last_price or a supported technical indicator (for example indicator='rsi:14' or 'macd:12,26,9' with component='histogram'). Arbitrary code and expressions are not accepted.
instrumentNo
candle_sizeNoMaximum candles fetched for indicator conditions. It must cover every requested indicator lookback.
candle_periodNoHTX candle interval used for indicator conditions: 1min, 5min, 15min, 30min, 60min, 4hour, 1day, 1week, or 1mon.60min
timeout_secondsNoHard maximum blocking duration (one hour). The budget includes polls and sleeps. Configure the MCP host tool deadline and outer yield_time_ms longer than this value so this tool, rather than an intermediate host yield, is the wake-up source.
poll_interval_secondsNoTarget minimum interval between read-only poll starts. A larger interval reduces API use but increases wake latency.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
matchYes
pollsYes
statusYes
productYes
warningsYes
elapsed_msYes
instrumentYes
failed_pollsYes
observationsYes
poll_attemptsYes
started_at_msYes
finished_at_msYes
successful_pollsYes
last_success_at_msYes
matched_conditionsYes
observation_age_msYes
requested_timeout_msYes
effective_deadline_msYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.7.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already mark it read-only and non-destructive. The description adds that it performs no code execution and that the agent receives no intermediate updates during the wait, which is useful for agent planning. Does not mention rate limits or auth, but those are less critical given the read-only annotation.

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 moderately long but every sentence adds value. It is well-structured with separate paragraphs for the core purpose, safety notes, and timeout guidance. No redundancy or 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?

Given the complexity of the tool (8 parameters, nested conditions), the description covers the essential operational aspects: condition semantics, indicator usage, timeout budgeting, and polling behavior. The output schema is present, so return values do not need explanation.

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

Parameters5/5

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

Goes beyond the schema: explains that conditions can override product/instrument, gives indicator examples, specifies candle_size must cover lookback, notes that timeout includes polls and sleeps, and explains poll_interval trade-offs. This meaningfully aids correct usage.

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 the specific purpose: block until bounded declarative market conditions match or timeout expires. Clearly identifies it as a read-only wait primitive, and the description distinguishes it from a future WebSocket daemon, clarifying its polling nature.

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?

Provides concrete guidance on configuring timeouts (yield_time_ms, host deadline) and warns about the lack of intermediate updates. Does not explicitly compare to sibling polling tools, but the blocking behavior is clearly implied and the timeout advice is actionable.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TeacherLi07/htx-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server