QuantGeeks GEX

Webinar schedule and recordings

quantgeeks_get_webinar_schedule

Read-onlyIdempotent

Without signing in: the whole session schedule, the public stream link while a session is live (from 30 minutes before the start to 10 minutes after the end), and YouTube and Vimeo recordings; never the members' join link. Signed in with a free QuantGeeks account: the same. With a QuantGeeks plan: the members' join link in place of the stream link, and every recording. Upcoming and live QuantGeeks team sessions with start and end times in US Eastern and canceled sessions marked canceled; the join link (members) or the public live-stream link (preview) only while the join window is open (from 30 minutes before the start to 10 minutes after the end); and recorded past sessions with their recording links, newest first (at most 20; detail 'all' lifts the cap). A session passcode is shown only on the QuantGeeks desk.

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_get_webinar_schedule"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	'summary' (default): the 20 newest recordings; 'all': every recording.

Output Schema

Name	Required	Description	Default
`as_of`	Yes
`access`	Yes
`notice`	Yes
`source`	Yes
`symbol`	Yes
`account`	No
`preview`	Yes
`pro_plan`	No
`sessions`	Yes
`truncated`	No
`recordings`	Yes
`account_note`	No
`empty_reason`	No
`truncated_more`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.1/5.0

Behavior3/5

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

This is the description's strong suit: auth tiers, a 20-record cap lifted by `detail`, newest-first ordering, a time-boxed join window, and a passcode that is only surfaced on the QuantGeeks desk far exceed the readOnly/idempotent annotations. However, the access rules are stated twice in near-identical wording, so the added information is diluted rather than extended.

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

Conciseness3/5

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

The first two sentences and the final paragraph restate the same tier rules and the same join-window timing, so roughly half the text is redundant. It is informative and reasonably front-loaded, but it would be materially stronger at half its length.

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?

With an output schema present, the description need not explain return shapes, and it covers everything else an agent needs: entitlement gating, window timing, ordering, cap, cancellation marking, and the passcode exclusion.

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?

Schema coverage is 100%, so `detail` is already fully documented as an enum with a default. The description nonetheless adds the consequence of the value — that the default caps at 20 and 'all' lifts the cap — which is useful meaning beyond the schema text.

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 names a specific resource (session schedule, live-stream link, and recordings) and makes the entitlement-dependent shape of the response explicit, including a hard exclusion ("never the members' join link"). An agent can tell this returns webinar scheduling and recording data, not pricing, options, or account data.

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?

It gives strong situational context: what you receive depends on sign-in state and plan, links exist only inside a 30-minutes-before to 10-minutes-after window, and canceled sessions are marked. It never names an alternative tool or an explicit when-not-to-call condition, but siblings are unrelated and the guidance is otherwise clear.

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?