Skip to main content
Glama

Ticker: Live Event Ticket Market

by com.findticker
OverviewDiscussionsAdmin

Venue Schedule

get_venue_schedule
Read-only

Shows the upcoming events at one venue, soonest first, with sale dates and the get-in price, plus its roof and a 7-day forecast. view venues finds venues instead: by name, or by state, country and capacity range, with their ids and upcoming event counts; use the official name, not a nickname. Use screen_events to rank a venue's events. Replaces find_venue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far forward to look, in days. Default 30, maximum 365.
viewNoschedule (default): one venue's events. venues: find venues and their ids.
limitNoMost events to return. Default and maximum 200.
stateNoKeep venues in this state or province, e.g. "TX". Matched against the same grouping key the venue directory orders by: the region code where the venue has one, its country code otherwise.
countryNoKeep venues in this country, by two-letter code, e.g. "US".
venue_idNoThe venue to read. Ticker venue id, `vn` plus ten characters, as returned by find_venue. A marketplace id also resolves with its `vs:` prefix, and bare until 2027-09-13. Omit it only when passing `venue_name`.
venue_nameNoA venue name. schedule: the best match is read. venues: the name to search for, or part of it.
capacity_maxNoKeep venues that hold at most this many people. Venues whose capacity is unknown are left out whenever either bound is given.
capacity_minNoKeep venues that hold at least this many people. Venues whose capacity is unknown are left out whenever either bound is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / capacity_max
      Added value: +{
+  "description": "Keep venues that hold at most this many people. Venues whose capacity is unknown are left out whenever either bound is given.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / capacity_min
      Added value: +{
+  "description": "Keep venues that hold at least this many people. Venues whose capacity is unknown are left out whenever either bound is given.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / country
      Added value: +{
+  "description": "Keep venues in this country, by two-letter code, e.g. \"US\".",
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / state
      Added value: +{
+  "description": "Keep venues in this state or province, e.g. \"TX\". Matched against the same grouping key the venue directory orders by: the region code where the venue has one, its country code otherwise.",
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / venue_name / description
      Previous value: -"A venue name instead of an id. The best match is used; when two venues share a name this picks one, so prefer find_venue and an id when the answer matters."New value: +"A venue name. schedule: the best match is read. venues: the name to search for, or part of it."
    • addedInput schema / properties / view
      Added value: +{
+  "description": "schedule (default): one venue's events. venues: find venues and their ids.",
+  "enum": [
+    "schedule",
+    "venues"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • removedInput schema / properties / days / maximum
      Removed value: -365
    • removedInput schema / properties / limit / maximum
      Removed value: -200
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavioral value beyond that: ordering (soonest first), the fields returned (sale dates, get-in price, roof, forecast), and a deprecation/migration note. It does not cover rate limits or auth, hence not a 5.

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?

Core behavior is front-loaded in the first sentence, followed by tightly packed routing constraints. Every clause carries information (return content, alternatives, deprecation) with no filler.

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?

For a 9-parameter, optional-only tool with no output schema, the description covers what gets returned and which mode to use, and flags that find_venue is superseded. Remaining gaps (seed parameter interplay, pagination) are minor.

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 the baseline is 3. The description meaningfully supplements the schema by explaining the two view modes and, notably, the 'official name, not a nickname' rule for venue_name — semantics the schema's maxLength/minLength text does not convey.

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?

Opens with a specific verb and resource ('Shows the upcoming events at one venue'), states ordering (soonest first) and return content (sale dates, get-in price, roof, 7-day forecast). It then explicitly separates itself from the venue-search mode and names sibling find_venue, so an agent can distinguish the two without opening schemas.

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?

Gives explicit routing: use view=venues to find venues (by name, state, country, capacity), use screen_events to rank a venue's events, and notes this 'Replaces find_venue'. It also warns to use the official name, not a nickname — a concrete when-to/how-to constraint.

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

All Ticker: Live Event Ticket Market toolsInspect
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