market_statusCheck the current trading status for all markets to determine whether a market is open or closed.
Get current market trading status for all markets.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| market_time | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.6.0Output schema / $defs / MarketStatusEntry / properties / delay_timestamp / descriptionRemoved value: -"Delayed-quote status timestamp (RFC3339)."Output schema / $defs / MarketStatusEntry / properties / delay_trade_status / descriptionRemoved value: -"Delayed-quote trading status label (same value set as `trade_status`)."Output schema / $defs / MarketStatusEntry / properties / market / descriptionRemoved value: -"Market code, e.g. \"US\" / \"HK\" / \"CN\" / \"SG\"."Output schema / $defs / MarketStatusEntry / properties / timestamp / descriptionRemoved value: -"Status snapshot timestamp (RFC3339)."Output schema / $defs / MarketStatusEntry / properties / trade_status / descriptionRemoved value: -"Trading status label, e.g. Trading / Closed / Mid-Day Break /\nPre-Market / Post-Market / Overnight / Unknown."Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / descriptionRemoved value: -"Returned by `market_status`. Wraps a `market_time` array, one entry per\nmarket. Subset of the wire response — `trade_status` is mapped from the\nupstream numeric code to a human label, and `timestamp` is converted to\nRFC3339."Output schema / properties / market_time / descriptionRemoved value: -"Per-market trading status entries."Output schema / titleRemoved value: -"MarketStatusResponse"v0.5.8Output schema / $defs / MarketStatusEntry / properties / trade_status / descriptionPrevious value: -"Trading status label: one of Pre-Open / Trading / Lunch Break /\nPost-Trading / Closed / Pre-Market / Post-Market / Unknown."New value: +"Trading status label, e.g. Trading / Closed / Mid-Day Break /\nPre-Market / Post-Market / Overnight / Unknown."v0.5.6Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "MarketStatusEntry": {
+ "properties": {
+ "delay_timestamp": {
+ "description": "Delayed-quote status timestamp (RFC3339).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "delay_trade_status": {
+ "description": "Delayed-quote trading status label (same value set as `trade_status`).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "market": {
+ "description": "Market code, e.g. \"US\" / \"HK\" / \"CN\" / \"SG\".",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timestamp": {
+ "description": "Status snapshot timestamp (RFC3339).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trade_status": {
+ "description": "Trading status label: one of Pre-Open / Trading / Lunch Break /\nPost-Trading / Closed / Pre-Market / Post-Market / Unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "description": "Returned by `market_status`. Wraps a `market_time` array, one entry per\nmarket. Subset of the wire response — `trade_status` is mapped from the\nupstream numeric code to a human label, and `timestamp` is converted to\nRFC3339.",
+ "properties": {
+ "market_time": {
+ "description": "Per-market trading status entries.",
+ "items": {
+ "$ref": "#/$defs/MarketStatusEntry"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "title": "MarketStatusResponse",
+ "type": "object"
+}v0.4.5v0.4.0v0.3.2v0.3.1v0.1.12Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. The description adds 'current' but no further behavioral traits beyond what annotations provide.
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?
Single sentence, no wasted words, front-loaded with purpose. Ideal conciseness.
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?
Given zero parameters, rich annotations, and presence of output schema, the description is complete for this simple tool.
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?
No parameters exist; schema coverage is 100%. Per rubric, baseline for 0 params is 4. Description adds no parameter detail but none is needed.
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?
The description clearly states the tool returns current market trading status for all markets, using a specific verb and resource, and distinguishes it from siblings like quote or candlesticks.
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?
No guidance on when to use this tool versus alternatives like quote or market_temperature; lacks context for when-not-to-use or expected prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/longbridge/longbridge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server