The List Access

Doorzoek The List Access-evenementen

search_events

Read-onlyIdempotent

Search upcoming and ongoing public The List Access events without opening the website. Combine event/artist/organizer text, city, genre, venue and inclusive dates in Europe/Amsterdam. Returns details, canonical links, source uncertainty and pagination. Date ranges include overnight events overlapping the selected days. Use from/to for dates; no purchases or guestlist registration.

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
`q`	No	Event, artist or organizer search text. All terms must match.
`to`	No	Inclusive YYYY-MM-DD end date.
`city`	No	City name, for example Amsterdam or Utrecht. Filters events to that city; omit for all cities.
`from`	No	Inclusive YYYY-MM-DD start date.
`page`	No	Result page, starting at 1 (default). Use nextPage from the previous response with the same filters and limit; pages beyond available results return an error.
`genre`	No	Music genre, for example House or Techno. Matches published genre labels using the calendar genre aliases; omit for all genres.
`limit`	No	Maximum number of events per result page, from 1 to 20; defaults to 10. Keep the same limit when requesting subsequent pages.
`venue`	No	Venue name, for example Paradiso. Matches the calendar venue identity; combine with city to distinguish venues with the same name.
`guestlist`	No	True selects listed guestlist actions; admission is never confirmed by this search.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 12, 2026

addedInput schema / properties / city / description

Added value: +"City name, for example Amsterdam or Utrecht. Filters events to that city; omit for all cities."

addedInput schema / properties / genre / description

Added value: +"Music genre, for example House or Techno. Matches published genre labels using the calendar genre aliases; omit for all genres."

addedInput schema / properties / limit / description

Added value: +"Maximum number of events per result page, from 1 to 20; defaults to 10. Keep the same limit when requesting subsequent pages."

addedInput schema / properties / page / description

Added value: +"Result page, starting at 1 (default). Use nextPage from the previous response with the same filters and limit; pages beyond available results return an error."

addedInput schema / properties / venue / description

Added value: +"Venue name, for example Paradiso. Matches the calendar venue identity; combine with city to distinguish venues with the same name."

First observedNov 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value on top: it states the return payload shape (details, canonical links, source uncertainty, pagination) and a non-obvious behavioral rule that date ranges include overnight events overlapping the selected days.

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?

Front-loads the core purpose and packs return shape, timezone, and overnight-range behavior into a few dense clauses with no repetition. The phrase 'without opening the website' is mildly promotional and the final clause awkwardly mixes the guestlist scope note with the purchase prohibition, but overall it is tight.

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 9-parameter, no-output-schema search tool this covers purpose, filter combination, date semantics, return contents, and out-of-scope actions — enough for an agent to call it correctly. Pagination mechanics and guestlist behavior are left entirely to the schema, which documents them adequately.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining that the text/city/genre/venue/date filters combine, that dates are interpreted in Europe/Amsterdam, and that overnight events overlap ranges — semantics the schema does not state. It does not clarify the guestlist parameter's effect, which is the one loose end.

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?

Uses a specific verb (Search) plus resource (public The List Access events) and states the combinable filter axes (text, city, genre, venue, dates) along with timezone scope. It is unambiguous what the tool does, though there are no siblings to differentiate against, so it sits just below the top mark.

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?

Gives clear context for use (look up upcoming/ongoing public events without visiting the site) and explicit out-of-scope declarations: no purchases and no guestlist registration. It also cues 'Use from/to for dates', steering away from ambiguous date handling. No named alternatives exist to compare against.

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

All The List Access 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.