events-search

search_events

Searches performances (concerts, theatre plays, festivals, stand-up shows and more) currently on sale on Biletyna.pl, a Polish ticketing platform. Every filter applies to a single performance, so city, date range and price always describe the same event. Results are deduplicated by title: each hit is the nearest matching performance of a distinct title, carrying its buy_url, venue, price and free places, plus aggregates for its city (city_events_total, city_next_event_date) and for the whole title (title_events_total, title_cities_total). Use "facets" for the distribution of matches across cities and categories. Only future performances are returned unless date_from says otherwise. Use list_performances(artist_id) for all dates of a title, get_title_details(artist_id) for its description and all cities. Full-text search is typo-tolerant. All content is in Polish. Prices are provided both in grosze (_min_price) and PLN (_min_price_pln); dates both as unix timestamps and human-readable *_text fields. "_meta.indexed_at" tells when the data was last refreshed - free places and prices are a snapshot from that moment.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`city`	No	City name filter (exact match, case-insensitive, diacritics required), e.g. "Warszawa".
`page`	No	Page number, starting at 1. Compare "page" with "total_pages" or read "has_more" to know whether more results exist.
`sort`	No	Result ordering. "date_asc" sorts by the performance date, "price_asc" by its cheapest ticket, "rating_desc" by the average rating of the title. Defaults to "relevance".	relevance
`query`	No	Search phrase: event name, performer or kind of event. Typo-tolerant. Use Polish terms when possible.
`date_to`	No	Latest performance date (YYYY-MM-DD).
`category`	No	Event category name filter (exact match), e.g. "koncert", "spektakl", "kabaret".
`date_from`	No	Earliest performance date (YYYY-MM-DD). Defaults to today - past performances are never returned.
`max_price`	No	Maximum price of the cheapest ticket for the performance, in PLN (not in grosze).
`min_rating`	No	Minimum average user rating of the title (1-5 stars).
`items_per_page`	No	Titles per page. Defaults to 10.

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 16, 2026

TDQS

A5/5.0

Behavior5/5

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

Discloses deduplication by title, result structure with aggregates, typo-tolerance, Polish content, snapshot freshness of prices, and date formats. Since no annotations exist, the description fully carries transparency.

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?

Front-loaded with purpose, then logically flows to filtering behavior, deduplication, aggregates, sibling guidance, and field format details. Every sentence adds value without repetition.

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?

Given no output schema, the description thoroughly explains return fields (buy_url, venue, price, free places, aggregates, meta.indexed_at) and sorting/facets usage. It is self-contained for effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical context: all filters apply to a single performance, results are deduped by title, and aggregates are included. This enhances understanding beyond the schema.

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 clearly states the tool searches performances on Biletyna.pl, listing specific event types. It distinguishes itself from siblings by explicitly mentioning list_performances and get_title_details for alternative use cases.

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?

Explicitly advises when to use sibling tools: 'Use list_performances(artist_id) for all dates of a title, get_title_details(artist_id) for its description and all cities.' Also clarifies scope (future performances only unless date_from is set).

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

All events-search 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?