Skip to main content
Glama

headless-oracle

by io.github.LembaGang

get_market_schedule

Returns holiday-aware trading session schedule with next open/close UTC timestamps for any of 28 exchanges. Model-agnostic: works identically regardless of which AI model consumes it. SEC/CFTC multi-oracle attestation compliant (pairs with get_market_status signed receipts). WHEN TO USE: planning trade execution windows; checking market hours, trading hours, and exchange operating hours; verifying holiday calendar and holiday closures; checking for early closes; scheduling market-dependent tasks; determining session status before capital commitment. Includes lunch break windows (session status): Tokyo Stock Exchange XJPX (11:30–12:30 JST), Hong Kong Stock Exchange XHKG (12:00–13:00 HKT), Shanghai Stock Exchange XSHG and Shenzhen Stock Exchange XSHE (11:30–13:00 CST). Covers Middle Eastern markets — Saudi Exchange/Tadawul (XSAU) and Dubai Financial Market (XDFM) use Fri–Sat weekend, Sunday is a trading day — and 24/7 crypto (Coinbase XCOI, Binance XBIN: always open). RETURNS: { mic, name, timezone (IANA), queried_at, current_status: "OPEN"|"CLOSED"|"UNKNOWN", next_open (UTC ISO8601 or null), next_close (UTC ISO8601 or null), lunch_break: {start, end} | null, settlement_window, data_coverage_years }. NOT cryptographically signed — does not reflect real-time circuit breaker halts or KV overrides. For authoritative signed status use get_market_status. Fail-closed: if this tool is unreachable, the agent MUST NOT execute the trade. LATENCY: sub-100ms p95 (pure schedule computation, no signing).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
micNoISO 10383 Market Identifier Code. Defaults to XNYS (NYSE). Call list_exchanges to see all 28 supported codes.

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is not cryptographically signed, does not reflect real-time circuit breaker halts or KV overrides, is fail-closed, and has sub-100ms p95 latency. This is exceptional transparency beyond any structured metadata.

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 lengthy but well-structured with clear sections (WHEN TO USE, RETURNS, caveats, latency). It is front-loaded with the core purpose, and every sentence carries operational value, making the length justified.

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 no output schema, the RETURNS section enumerates all fields precisely. The tool's complexity (28 exchanges, holiday calendars, lunch breaks, special weekend patterns, crypto 24/7) is fully addressed, and fail-closed behavior is specified for safe agent use.

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?

The schema fully documents the sole parameter (mic) with an enum and description, achieving 100% coverage, so the baseline is 3. The tool description adds some context about 28 exchanges but does not enrich the parameter syntax or meaning beyond what the schema already provides.

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?

The description opens with a specific verb (Returns) and a clear resource (holiday-aware trading session schedule) scoped to 28 exchanges. It distinguishes from the sibling get_market_status by clarifying it provides schedule timestamps rather than signed status.

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

Usage Guidelines5/5

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

An explicit 'WHEN TO USE' list enumerates concrete scenarios such as planning trade execution windows and checking holiday closures. It also explicitly directs users to get_market_status for authoritative signed status and notes what this tool does not reflect, providing clear exclusion criteria.

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

All headless-oracle toolsInspect
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.4/5.0
Disambiguation3/5

get_market_schedule and get_market_status both provide active status, causing potential confusion. However, descriptions clearly distinguish schedule planning from signed pre-trade verification, and the other two tools are distinct.

Naming Consistency4/5

Three tools use 'get_' prefix while one uses 'list_', a minor deviation. The naming is otherwise consistent and follows a predictable verb_noun pattern.

Tool Count5/5

Four tools is well-scoped for a market oracle server, covering discovery, schedule, status, and payment without unnecessary bloat.

Completeness5/5

The tool surface covers the full lifecycle: list exchanges, get schedule for planning, get status for execution gating, and payment options for access. No obvious gaps for the stated purpose.

Resources