events-search
Server Details
Event search at Biletyna.pl - Poland's top-rated ticket distributor, widest offer in all cities.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: searching events, listing performances, retrieving event details, and retrieving title details. There is no overlap in their functionality.
All tool names follow a consistent verb_noun pattern with snake_case (get_*, list_*, search_*). The naming is predictable and uniform.
With 4 tools, the server is well-scoped for its purpose of searching and retrieving event details. Each tool serves a necessary function without redundancy.
The tool surface covers the full workflow: search (search_events), list performances (list_performances), and get details (get_event_details, get_title_details). No obvious gaps for a read-only event search API.
Available Tools
4 toolsget_event_detailsAInspect
Returns a single performance identified by event_id (as returned by search_events or list_performances), with its title, venue, date, price, free places and buy_url. Free places and price are a snapshot taken at "_meta.indexed_at".
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Performance identifier - an event_id value from search_events or list_performances results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that free places and price are snapshots at '_meta.indexed_at', a useful behavioral trait. No other behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the core purpose, the second adds a nuance about snapshot timing. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description adequately lists return fields and a behavioral note. However, it could mention the response format (e.g., JSON object) for completeness. Sibling tools are listed but differentiation is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds value by specifying the source of event_id, reinforcing the schema's description. This is helpful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a single performance identified by event_id, listing specific fields (title, venue, date, price, free places, buy_url) and distinguishes from siblings like search_events (which returns multiple events) and list_performances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the event_id comes from search_events or list_performances, providing clear context for when to use this tool. It does not explicitly state when not to use it, but the single-event purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_title_detailsAInspect
Returns a single title currently on sale on Biletyna.pl, identified by artist_id (as returned by search_events). "title" holds the description, average user rating, top user reviews and the nearest performance. "cities" lists every city where the title is played - one entry per city with its buy_url, number of performances, nearest date and lowest price. Use list_performances(artist_id, city) for the individual dates.
| Name | Required | Description | Default |
|---|---|---|---|
| artist_id | Yes | Title identifier - the artist_id field from search_events results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output structure but does not explicitly state it is read-only or non-destructive. However, as a get/fetch operation, behavior is implicit and no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loads the main purpose, then provides output details and usage link to sibling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description adequately explains return structure. Could note error behavior (e.g., not found) but not essential. Overall complete given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter artist_id is fully described in schema. Description adds minimal extra value beyond schema (just restates source). Schema coverage is 100%, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns a single title by artist_id, and explicitly describes the content of 'title' and 'cities' fields. Distinguishes from sibling tools by referencing search_events and list_performances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies to use artist_id from search_events, and directs to list_performances for individual dates, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_performancesAInspect
Lists every performance of a single title, ordered by date, optionally narrowed to one city and a date range. Use this when the user asks for all dates of a title, or for its dates in a given city or on a given weekend - search_events returns only the nearest performance per title. Each performance carries its own venue, date, price, free places and buy_url. Only future performances are returned unless date_from says otherwise.
| 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. | |
| date_to | No | Latest performance date (YYYY-MM-DD), inclusive. | |
| artist_id | Yes | Title identifier - the artist_id field from search_events results. | |
| date_from | No | Earliest performance date (YYYY-MM-DD). Defaults to today. | |
| items_per_page | No | Performances per page. Defaults to 20. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only future performances are returned unless date_from is provided, and lists return fields (venue, date, price, free places, buy_url). No annotations exist, so description carries full burden; it covers key behaviors well though pagination details are left to schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage context and behavior details. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions key return fields. Covers default date behavior and filter options. Lacks explicit mention of sort order (assumed ascending by date) but overall is complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by clarifying 'city' filter semantics (exact match, case-insensitive, diacritics required) and explaining that 'artist_id' comes from search_events results. This aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lists every performance of a single title', specifying the verb and resource. It distinguishes from sibling 'search_events' by noting 'search_events returns only the nearest performance per title'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'when the user asks for all dates of a title, or for its dates in a given city or on a given weekend'. Also explicitly contrasts with 'search_events' as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsAInspect
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.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses deduplication by title, return of nearest matching performance with aggregates, typo-tolerance, future-only behavior, price unit (grosze and PLN), date formats, and indexed_at snapshot. It doesn't mention rate limits or error handling but covers key behaviors well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and provides detailed information in a structured manner. While it is somewhat lengthy, every sentence adds value. Could be slightly more succinct without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains return fields (buy_url, venue, price, free places, aggregates), mentions facets, indexed_at as snapshot time, and pagination hints (page param description). It gives a fairly complete picture of what the tool returns and how data is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, each parameter already has a detailed description. The tool description adds overall context (e.g., filters apply to single performance, dedup) but does not provide additional meaning for individual parameters beyond what the schema already specifies. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches performances (concerts, theatre plays, etc.) currently on sale. It distinguishes from siblings by explicitly saying 'Use list_performances(artist_id) for all dates of a title, get_title_details(artist_id) for its description and all cities.' The verb 'Searches' combined with the resource and scope is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool for searching/finding events and when to use alternatives. It mentions that filters apply to a single performance, that only future performances are returned unless date_from says otherwise, and directs to sibling tools for more details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!