Use this when a user asks for events tonight, this week, or this weekend and the assistant should ask only the missing event type, vibe, budget, area, or avoid-preference questions before searching.
AI agents call get_event_search_followups to retrieve information from Events without modifying anything — typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
city | string | — | City name, for example berlin or new york. |
free | boolean | — | |
vibe | array | — | |
when | string | — | Date preset: today, tonight, tomorrow, weekend, week, this week, any, or YYYY-MM-DD. |
avoid | array | — | Terms to penalize in recommendations. |
limit | number | — | Results per page (default 12). The response's count field is the TOTAL matching events — raise limit or use offset to page through more. |
pride | boolean | — | |
query | string | — | Keyword search. |
venue | string | — | |
genres | array | — | |
offset | number | — | |
date_to | string | — | Inclusive end date in YYYY-MM-DD format. |
Parameters from the server's own tool schema.
This tool retrieves or generates follow-up questions to refine search parameters. It performs no side effects—no events are created, modified, or deleted; no money is exchanged; no code is executed. It is a preparatory Read operation that helps contextualize a subsequent search action.
From the tool's definition Tool description explicitly states 'before searching' and the name 'get_event_search_followups' indicates retrieval of clarifying questions. No data is created, modified, deleted, or financial transactions occur.
Risk signalsHigh parameter count (20 properties)
Attacks that exploit this kind of access
Use this when a user asks for events tonight, this week, or this weekend and the assistant should ask only the missing event type, vibe, budget, area, or avoid-preference questions before searching. It is categorised as a Read tool in the Events MCP Server, which means it retrieves data without modifying state.
get_event_search_followups accepts 12 parameters: city, free, vibe, when, avoid, limit, pride, query, venue, genres, offset, date_to. The full parameter table on this page comes from the server's own tool schema.
Register the Events MCP server in PolicyLayer and add a rule for get_event_search_followups: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Events. Nothing to install.
get_event_search_followups is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_event_search_followups rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for get_event_search_followups. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_event_search_followups is provided by the Events MCP server (uplayground-events). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
get_event_search_followups is one line of Events's registry record.
The record carries the whole server: verified identity, auth posture, risk grade, every tool classified, recommended policy — re-checked continuously.
Teams ship this data inside their own products. See what a licence covers →