Skip to main content
Glama

Ticker: Live Event Ticket Market

Get Venue Schedule

get_venue_schedule
Read-only

Lists one venue's upcoming events, soonest first, with sale dates and the get-in price, plus the venue's roof and a 7-day weather forecast. Use it when the person asks what is on at a venue. view venues finds venues and their ids instead. To filter or rank a venue's events by price, demand or inventory, use screen_events.

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": "get_venue_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow far forward to look, in days. Default 30, maximum 365. Read only when neither date is passed.
pageNoThe page of the window to read, soonest first, `limit` events a page. has_more says whether a next page holds more.
viewNoschedule (default): one venue's events, by venue_id or venue_name. venues: find venues and their ids, by name (the official name, not a nickname) or by state, country and capacity, with each venue's upcoming event count. sections: what each section at one venue costs across its next upcoming events (events, default 10), by venue_id or venue_name: average get-in and median, before fees and all-in, open tickets and listings, dearest first.
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.
eventsNoHow many of the venue's next upcoming events to average over, soonest first. Default 10, maximum 20.
countryNoKeep venues in this country, by two-letter code, e.g. "US".
date_toNoOnly events before this instant, ISO 8601. With only date_to the window starts now.
venue_idNoThe venue to read. Ticker venue id, `vn` plus ten characters, as view venues returns it. A marketplace id also resolves with its `vs:` prefix, and bare until 2027-09-13. Omit it only when passing `venue_name`.
date_fromNoOnly events on or after this instant, ISO 8601. With only date_from the window runs a year from it.
venue_nameNoA venue name. schedule and sections: 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. Changed1 schema field changed
    • addedInput schema / properties / page / default
      Added value: +1
  2. Changed4 schema fields changed
    • addedInput schema / properties / events
      Added value: +{
      +  "description": "How many of the venue's next upcoming events to average over, soonest first. Default 10, maximum 20.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / properties / venue_name / description
      Previous value: -"A venue name. schedule: the best match is read. venues: the name to search for, or part of it."New value: +"A venue name. schedule and sections: the best match is read. venues: the name to search for, or part of it."
    • changedInput schema / properties / view / description
      Previous value: -"schedule (default): one venue's events, by venue_id or venue_name. venues: find venues and their ids, by name (the official name, not a nickname) or by state, country and capacity, with each venue's upcoming event count."New value: +"schedule (default): one venue's events, by venue_id or venue_name. venues: find venues and their ids, by name (the official name, not a nickname) or by state, country and capacity, with each venue's upcoming event count. sections: what each section at one venue costs across its next upcoming events (events, default 10), by venue_id or venue_name: average get-in and median, before fees and all-in, open tickets and listings, dearest first."
    • changedInput schema / properties / view / enum
      Previous value: -[
      -  "schedule",
      -  "venues"
      -]New value: +[
      +  "schedule",
      +  "venues",
      +  "sections"
      +]
  3. Changed6 schema fields changed
    • addedInput schema / properties / date_from
      Added value: +{
      +  "description": "Only events on or after this instant, ISO 8601. With only date_from the window runs a year from it.",
      +  "format": "date-time",
      +  "type": "string"
      +}
    • addedInput schema / properties / date_to
      Added value: +{
      +  "description": "Only events before this instant, ISO 8601. With only date_to the window starts now.",
      +  "format": "date-time",
      +  "type": "string"
      +}
    • changedInput schema / properties / days / description
      Previous value: -"How far forward to look, in days. Default 30, maximum 365."New value: +"How far forward to look, in days. Default 30, maximum 365. Read only when neither date is passed."
    • addedInput schema / properties / page
      Added value: +{
      +  "description": "The page of the window to read, soonest first, `limit` events a page. has_more says whether a next page holds more.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / properties / venue_id / description
      Previous value: -"The 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`."New value: +"The venue to read. Ticker venue id, `vn` plus ten characters, as view venues returns it. A marketplace id also resolves with its `vs:` prefix, and bare until 2027-09-13. Omit it only when passing `venue_name`."
    • changedInput schema / properties / view / description
      Previous value: -"schedule (default): one venue's events. venues: find venues and their ids."New value: +"schedule (default): one venue's events, by venue_id or venue_name. venues: find venues and their ids, by name (the official name, not a nickname) or by state, country and capacity, with each venue's upcoming event count."
  4. 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"
      +}
  5. Changed2 schema fields changed
    • removedInput schema / properties / days / maximum
      Removed value: -365
    • removedInput schema / properties / limit / maximum
      Removed value: -200
  6. First observed

TDQS

A3.8/5.0
Behavior3/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 the safety profile is covered. Beyond that the description adds useful output context (sort order, sale dates, get-in price, roof, 7-day forecast) that no output schema provides. It says nothing about pagination limits, freshness of pricing, or the venue-matching tolerance for venue_name, which are the behaviors an agent would most want disclosed.

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?

Three short sentences, front-loaded with the capability before the routing advice, with no filler. The middle sentence about 'view venues' is slightly awkward and the third sentence competes with schema content the agent will see anyway, but overall it is tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, zero-required tool the description covers only the default `schedule` mode; the `sections` and `venues` modes of the `view` enum are left entirely to the schema, and no output schema exists to explain return shape. What is present is accurate and helpful, but a tool this multi-modal would benefit from a sentence on when to reach for the other modes.

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 the `view` enum, windowing, pagination and capacity filters in detail, so the baseline of 3 applies. The description adds essentially no parameter meaning of its own — it never mentions `days`, `date_from`/`date_to`, `page`, or the capacity bounds.

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 uses a specific verb and resource ('Lists one venue's upcoming events, soonest first') and enumerates the returned payload (sale dates, get-in price, venue roof, 7-day forecast). It also explicitly separates itself from screen_events and from the venue-lookup path, so an agent can pick it without opening any schema.

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 a concrete trigger ('when the person asks what is on at a venue') and names a real alternative with the condition that selects it ('To filter or rank a venue's events by price, demand or inventory, use screen_events'). The weaker point is that 'view venues finds venues and their ids instead' refers to this tool's own `view` mode rather than a sibling tool, which could momentarily send an agent looking for a separate tool of that name.

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