Crawlora MCP

stubhub_explore

Read-only

Discover StubHub ticket-resale events near a location within a date range, optionally bounded by price and by category.

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": {
      "lat": "<lat>",
      "lon": "<lon>"
    },
    "name": "stubhub_explore"
  }
}

Input Schema

Name	Required	Description
`to`	No	Optional. End of the date range, same accepted formats as from. Defaults to 14 days after from.
`lat`	Yes	Required. Latitude, -90 to 90.
`lon`	Yes	Required. Longitude, -180 to 180.
`from`	No	Optional. Start of the date range: RFC3339 (2026-09-15T00:00:00Z) or a bare date (2026-09-15). Defaults to now.
`price_max`	No	Optional. Maximum ticket price filter.
`price_min`	No	Optional. Minimum ticket price filter, whole units of StubHub's local display currency for the request's region.
`category_id`	No	Optional. Filter to one category/subcategory id. stubhub-categories discovers ids with a currently-listed event nearby (a small subset, not the full taxonomy). Known-good ids: NBA 6453, MLB 6456, NFL 5084, NHL 4871, MLS 5062, Tennis 1012, Golf 1009 (Sports); Pop/Rock 260542, Alternative Music 1059, Classical 1014, R&B 1027, Rap and Hip-Hop Music 1026 (Concerts); Comedy 1015, Musicals 1017, Plays 358959, Family 2294 (Theater); Festival Tickets 1023 (works alone, no top_level_category_id needed).
`top_level_category_id`	No	Optional. Filter to one top-level vertical: 0 (all categories, default), 1 (Theater), 2 (Sports), 3 (Concerts).

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 5, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope context (ticket-resale secondary market, location+date bounded, price/category optional filters) but says nothing about result volume, pagination, or currency handling beyond what the schema already notes.

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?

A single well-formed sentence with the resource front-loaded and the optional constraints trailing. Every clause earns its place and nothing is padded.

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?

With an output schema present, return values need no explanation, and annotations cover the read-only/open-world profile. The description plus rich schema gives an agent enough to call correctly; only cross-tool routing (which sibling to prefer) is left 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%, so lat/lon/from/to/price/category semantics are fully documented in the schema itself, including defaults, formats, and known-good category ids. The description only restates the filter categories and adds no format or constraint detail. Baseline 3 applies.

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?

States a specific verb (Discover) and resource (StubHub ticket-resale events) with scoping (near a location, within a date range, optionally bounded by price/category). This is clearly a geo+date discovery tool, distinguishable in spirit from stubhub_venue_events or stubhub_performer_events, though those siblings are never named.

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 context is implied by 'near a location within a date range' — an agent can infer this is for broad geographic browsing rather than a known performer/venue. However there is no explicit when-to-use vs stubhub_search or stubhub_categories guidance, and no exclusions.

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

All Crawlora MCP 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?