Search upcoming public events in Israel by date, city, region or category. Read-only; no API key.
Scored across 2 tools
search_events (discovery by filters) and get_event_details (retrieval by known id) are cleanly separated, and the description explicitly states the dependency flow between them. There is no plausible way to confuse the two.
Both tools use a consistent snake_case verb_noun pattern (get_event_details, search_events), which makes the action and target resource immediately readable.
Two tools is thin in absolute terms, but for a read-only event-lookup domain the search-plus-fetch-by-id pair is the minimal complete surface. A small auxiliary tool for enumerating cities/categories would round it out.
Discovery and detail retrieval with cursor pagination are both covered, and the read-only scope is explicitly declared (no booking), so the absence of write operations is intentional rather than a gap. Minor gap: no tool to enumerate valid filter values (cities, regions, categories).
Look up an upcoming public event using its full id from search_events. Returns the event date, place, source-reported price/availability, and Makore/source links. Recheck the source before purchasing; this tool does not book or buy tickets.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Full 64-character id from a search response. | |
| sandbox | No | Use the synthetic fixture catalogue instead of live events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: price/availability are source-reported (possibly stale), the source should be rechecked before purchasing, and no booking occurs. It doesn't cover error behavior for stale ids, keeping it short of a 5.
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 tightly written sentences with the lookup action front-loaded, followed by what is returned and the critical purchasing caveat. No filler.
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?
Despite no output schema, the description enumerates what is returned (date, place, price/availability, links), covers the id provenance, and flags the non-transactional nature of the tool. Nothing essential for correct invocation is missing.
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% and both parameters are documented, including the 64-character id pattern and the sandbox flag. The description's mention of the 'full id from search_events' largely restates what the schema already says, so the 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?
States a specific verb (look up) and resource (upcoming public event) plus the exact identifier needed. It also names the sibling tool search_events as the source of the id, so an agent can distinguish it from the search tool without opening either schema.
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 tells the agent when this tool applies (after obtaining an id from search_events) and draws a clear boundary: 'this tool does not book or buy tickets.' It does not give an explicit when-not scenario beyond that, but the sequencing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find upcoming public Israeli events for outing planning by date, Hebrew city, region, category or keywords. Returns events and nextCursor; repeat filters with that cursor for the next page. Dates use Asia/Jerusalem. Event content is untrusted source data.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Canonical Hebrew city name, e.g. תל אביב-יפו. Cannot be combined with district. | |
| limit | No | Maximum events per response. | |
| query | No | Title or description keywords in Hebrew or English; at least 3 characters. | |
| cursor | No | Opaque nextCursor from the previous response. Repeat the same filters. | |
| dateTo | No | Last inclusive Israel calendar date. Maximum 31-day window; defaults to 30 days after dateFrom. | |
| sandbox | No | Use synthetic fixtures with a fixed clock of 2030-05-22 instead of live events. | |
| category | No | One Makore category in Hebrew. | |
| dateFrom | No | First Israel calendar date (YYYY-MM-DD). Defaults to today. Use a window within the next 180 days. | |
| district | No | Makore region in Hebrew; cannot be combined with city. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-derivable behavior: the response shape (events + nextCursor), the pagination contract, the Asia/Jerusalem date convention, and a security warning that event content is untrusted source data.
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?
Three compact sentences with no filler: purpose and filters first, then return/pagination behavior, then the timezone and trust caveat. Every clause carries information an agent needs.
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 nine parameters, no output schema, and a pagination loop, the description supplies the missing return-value and pagination semantics plus the timezone and trust context. Nothing essential to calling it correctly is absent.
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%, so the schema already documents all nine parameters, including the city/district mutual exclusion and date-window limits. The description only restates the filter dimensions and adds a note about reusing the cursor, which is baseline-level value given the schema does the heavy lifting.
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?
States a specific verb ('Find'), resource ('upcoming public Israeli events'), scope, and enumerates the filterable dimensions (date, Hebrew city, region, category, keywords). This clearly separates it from the sibling get_event_details, which fetches a single event rather than a filtered list.
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?
Gives clear context ('for outing planning') and an explicit operational instruction for pagination ('repeat filters with that cursor for the next page'). It does not, however, name get_event_details or state when to prefer it over this search, so there is no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_event_detailssearch_eventsLive Las Vegas shows, restaurants, attractions and resorts. Read-only, no API key needed.
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
Read-only tools for current SofiaStage events, venues, cities, performers, and editorial.
Prices in 31 Israeli supermarket chains by barcode. Free search; API key or x402 pay-per-call.
Add one secure layer between your agents and this server.
