QuantGeeks GEX

Last price

quantgeeks_get_last_price

Read-onlyIdempotent

Without signing in: the last price for any supported name, delayed 15 minutes (the last 1-minute bar that closed by then, or the last close outside the session). Signed in with a free QuantGeeks account: the same. With a QuantGeeks plan: live. The last price for a supported name (see quantgeeks_list_symbols: SPX, SPY, QQQ, VIX and the rest), from QuantGeeks' own bars: the newest 1-minute bar close while the session is open, and the latest daily close when it is shut, with the basis and as-of time stated. Any other symbol is refused with the list of supported names. Without a plan the same answer is delayed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "quantgeeks_get_last_price"
  }
}

Input Schema

Name	Required	Description	Default
`symbol`	Yes	Ticker, e.g. SPX (maps to its 0DTE option root SPXW), SPY, QQQ, VIX.

Output Schema

Name	Required	Description	Default
`as_of`	Yes
`basis`	Yes
`price`	Yes
`access`	Yes
`notice`	Yes
`source`	Yes
`symbol`	Yes
`account`	No
`preview`	Yes
`session`	No
`pro_plan`	No
`truncated`	No
`close_date`	No
`account_note`	No
`delayed_by_min`	No
`truncated_more`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.9/5.0

Behavior5/5

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

The annotations already establish that this is a safe, idempotent, closed-world read, and the description adds a lot on top: data provenance (QuantGeeks' own bars), latency that depends on auth tier, which bar is chosen when the session is open versus shut, the as-of time and basis included in the answer, and the refusal behavior for unsupported symbols. That is exactly the kind of context the annotations cannot carry.

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

Conciseness4/5

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

The size is reasonable for the tiered behavior it must explain, and the critical delay condition appears early. The free-tier case is stated twice: once as 'the same' for a free account, and again as 'Without a plan the same answer is delayed' at the end. That is minor redundancy rather than a structural flaw.

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?

The tool is simple (one required parameter), an output schema covers the return values, and the annotations cover safety, so the description only needs to explain the tiered latency, the symbol set, and the error path, all of which it does. The only shortfall is that it does not contrast this tool with the bars or symbols siblings, leaving the boundary implicit.

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?

Schema description coverage is 100%, and the schema already explains that symbol maps to its 0DTE option root (SPX becomes SPXW). The description adds some meaning by pointing to quantgeeks_list_symbols for the supported set and by noting that unsupported names are refused with the full list, which helps an agent avoid errors. Otherwise it does not expand on format or syntax beyond the schema.

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 description states a specific verb and resource: it returns the last price for a supported symbol, sourced from QuantGeeks' own bars. It also distinguishes the intraday and outside-session cases (the newest 1-minute bar close while the session is open, the latest daily close when it is shut). It never names a sibling tool it is not, such as quantgeeks_get_price_bars for historical series, so a reader must infer the boundary from context.

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?

Implicit guidance covers the main case: call this when you want a current price, and check quantgeeks_list_symbols for valid names. Auth-tier behavior (anonymous and free = 15-minute delay, plan = live) is clearly spelled out. However, the description never says when to use a different tool instead, for example the bars endpoint for history, so the distinction between this tool and its siblings stays implicit.

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

All QuantGeeks GEX tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?