Skip to main content
Glama

QuantGeeks GEX

Covered symbols and market status

quantgeeks_list_symbols
Read-onlyIdempotent

Without signing in: every supported symbol (marking the SPX, SPY, QQQ, META and AAPL that Active Levels covers without a plan) and the market status: open or closed, the next session, the next early close and upcoming holidays. Signed in with a free QuantGeeks account: the same. With a QuantGeeks plan: the same. Lists every symbol this QuantGeeks deployment can serve (a symbol whose data host is not connected here is left out, so every name listed can be used with the other tools) (with its replay range and whether the free preview covers it) and the market status now: open or closed, the next session date, today's or the next early close as a clock time, and the holidays in the next 30 days. SPX is served as its 0DTE option root SPXW and NDX as NDXP.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "quantgeeks_list_symbols"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
as_ofYes
accessYes
marketYes
noticeYes
sourceYes
symbolYes
accountNo
mappingYes
previewYes
symbolsYes
pro_planNo
truncatedNo
account_noteNo
truncated_moreNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world profile, but the description adds real behavior: results are identical across anonymous, free-account, and plan tiers, symbols whose data host is not connected to this deployment are silently omitted, and SPX/NDX are surfaced as their 0DTE roots SPXW/NDXP. What is missing is anything about response shape or caching freshness, but the annotation bar is already met.

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

Conciseness2/5

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

The description makes the same point three times ("Signed in with a free account: the same. With a plan: the same.") and then restates the entire symbol-plus-market-status payload in a second, longer clause. The valuable facts — deployment filtering, SPXW/NDXP aliasing, 30-day holiday window — are buried inside the repetition rather than front-loaded.

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?

An output schema exists, so the description need not enumerate return fields, and it still covers the two things an agent cannot infer: which symbols are omitted per deployment and how index roots are renamed. For a zero-parameter discovery tool this is close to complete, with only freshness/refresh cadence left unspecified.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4 and the description has no parameter semantics to supply. It does clarify that no auth or plan is required, which is the only input-adjacent concern for a parameterless call.

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 first sentence names a concrete resource set (every supported symbol) plus a second payload (market status: open/closed, next session, early close, holidays), and the description ties it to the other tools by saying "every name listed can be used with the other tools." The purpose is clear, but it is a dual-purpose tool described in two overlapping passes, which slightly blurs the core statement.

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?

Usage is only implied: the phrasing "so every name listed can be used with the other tools" suggests this is a discovery/prerequisite call before invoking data tools. There is no explicit when-to-use versus a sibling, no when-not guidance, and no stated prerequisites beyond the auth-tier sentence.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources