search_eventsSearch real-world local events (currently: Niagara-on-the-Lake, Ontario) — live music, theatre performances, tastings, markets, tours — by keyword, typo-tolerant, with optional date range. This is a things-to-do calendar, not a software/system event log.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| area | No | Area id, e.g. 'notl'. Defaults to the only area. | |
| from | No | ||
| limit | No | ||
| query | Yes | Search text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavioral traits: typo-tolerant search, current geographic limitation (Niagara-on-the-Lake), and the domain scope (things-to-do calendar). It does not cover return format, pagination, or error behavior, but the disclosed traits are significant and add value beyond the input 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?
The description is two sentences with no wasted words. The first sentence front-loads the core purpose and key attributes (location, content types, typo tolerance, date range), and the second sentence adds a crucial disambiguation. Every phrase contributes to understanding the tool's purpose and scope.
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?
For a search tool with five parameters, no annotations, and no output schema, the description provides a solid overview: it clarifies the domain, scope, and key capabilities. It lacks explicit guidance on result format or pagination, but the overall context is sufficient for an agent to select and invoke the tool appropriately in most cases.
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 only 40%, with query and area having explicit descriptions. The description adds semantics for the date-range parameters (to/from) by mentioning 'optional date range' and clarifies query behavior via 'typo-tolerant.' However, it does not explain the limit parameter or provide any format details for from/to, leaving gaps that the schema does not fill.
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 the tool searches real-world local events, with specifics on content types (live music, theatre, etc.) and a key differentiator: it's for things-to-do, not system event logs. This distinguishes it from sibling tools like get_event or whats_on.
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 provides clear context for when to use this tool: searching for local, real-world events with keyword and optional date range. It explicitly clarifies it is not a software/system event log, which helps avoid misuse. However, it does not explicitly name alternatives like 'use get_event for details' or 'use whats_on for current listings,' though sibling names imply these.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: direct retrieval of events/venues via get_event/get_venue, keyword search via search_events, curated summaries via whats_on, itinerary planning via plan_visit, and subscription management via subscribe. There is no meaningful overlap that would confuse an agent.
Most tools follow a verb_noun pattern: get_event, get_venue, search_events, plan_visit. The exceptions are 'whats_on' (an idiomatic phrase) and 'subscribe' (a bare verb), but these are still intuitive and don't create confusion. Overall, the naming is mostly consistent with minor deviations.
Six tools is perfectly scoped for a local events and things-to-do server. Each tool covers a necessary function without redundancy or bloat, making the set feel complete yet manageable.
The core domain is well covered: searching, retrieving event/venue details, getting a curated overview, and planning a visit. Minor gaps include no direct way to list events for a specific venue or manage subscription status (e.g., unsubscribe), but these are peripheral and agents can work around them with existing tools.