EventApp — pasākumi Latvijā / events in Latvia

Search events in Latvia

search_events

Read-onlyIdempotent

Find events in Latvia (concerts, theatre, exhibitions, festivals, cinema, kids' events, nightlife…) on a day or in a date range, optionally in one city, one category, matching words, free only, or from a time of day. With no dates it searches today in Riga time. The answer says today's date in Riga; showings that ended earlier today are left out. Each event has its EventApp page (url) to cite, the start time with its offset, venue, city, price and the ticket link.

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

Input Schema

Name	Required	Description
`city`	No	City or town in Latvia, e.g. Rīga, Riga, Liepāja, Jūrmala. Diacritics optional. list_cities names them all.
`when`	No	A named window in Riga time: today, tomorrow, weekend (Friday to Sunday; on a weekend day, what is left of it), week (today to Sunday), upcoming (everything ahead). Overrides date_from/date_to.
`limit`	No	How many events to return (default 20, at most 50).
`query`	No	Words that must all appear in the title, venue, city, organizer or categories, e.g. a performer, a venue or 'jazz'. Latvian or English; diacritics optional.
`offset`	No	Skip this many results; pass the previous answer's next_offset for the next page.
`date_to`	No	Last day, inclusive (at most 92 days after date_from). Omit for one day, YYYY-MM-DD, Europe/Riga calendar day.
`category`	No	Category, in English or Latvian: Music (concerts), Theater, Movie (cinema), Comedy, Dance, Exhibition, Festival, Sports, Food, Education, Family (kids), Nightlife, Market. list_categories names them all.
`date_from`	No	First day, YYYY-MM-DD, Europe/Riga calendar day.
`free_only`	No	Only events known to be free of charge.
`from_time`	No	Only showings starting at or after this Riga clock time, HH:MM (e.g. 18:00 for 'this evening'). All-day events are kept.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish this as a read-only, idempotent, non-destructive query, so the description's added value is elsewhere: it discloses the Riga-time default window and that showings that ended earlier today are dropped from results. With no output schema, it also carries the return-shape burden and does so adequately by naming url, start time with offset, venue, city, price and ticket link.

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 sentences, front-loaded with the core action and followed by the default and the return contract. The parenthetical category list is slightly long but doubles as a scope signal; no sentence is 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 ten-parameter search with no output schema, the definition covers the essentials: default window, timezone, filter combinations, excluded past showings, and result fields. The only real omission is that paging is documented solely in the schema and the response envelope (e.g. next_offset) is never described in prose.

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 the per-parameter documentation is already complete, including the 92-day date_to cap, pagination via offset/next_offset, and the when enum's override behavior. The description restates the filter set in prose but adds no syntax or interpretation beyond the schema, which is the expected baseline 3.

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?

The description opens with a clear verb-plus-resource statement ('Find events in Latvia') and enumerates concrete event types, so the agent knows exactly what domain this covers. The day/date-range framing implicitly separates it from events_happening_now, but it never names that sibling or any other, so the differentiation is left to inference.

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?

It gives useful operational context: no dates means today in Riga time, and it lists the combinable filters (city, category, words, free, from_time). What it lacks is explicit routing advice — nothing says to call get_event for a single event's details, list_cities/list_categories to resolve names, or events_happening_now for live listings.

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

All EventApp — pasākumi Latvijā / events in Latvia 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?