Find aviation events: airshows, fly-ins, workshops and club meets. Public and read-only.
Scored across 5 tools
search-events and featured-events both return event lists and could be conflated, though the descriptions clarify that featured is a curated home-page selection. get-event, list-countries, and list-event-types are clearly distinct lookups, so boundaries are mostly unambiguous.
Kebab-case is used throughout, with get-, list-, and search- verbs preceding nouns, giving a predictable pattern. featured-events is the only name lacking a verb, a minor deviation.
Five tools for a read-only public event directory is a tight, well-scoped set where each tool earns its place. It could arguably include one or two more lookup affordances, but nothing is redundant.
The surface covers discovery (search/featured), detail retrieval (get-event), and reference data (countries, event types) for a read-only browsing domain where booking happens off-site via URLs. Gaps exist for venue/organiser-level queries, but core workflows have no dead ends.
The events Events.Aero is featuring right now, the same selection as the lead row of the home page, optionally for one country. Each includes its public event page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter country code, e.g. GB: list-countries lists the live countries; a soft-launched country is answered only when named |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds a useful behavioral detail that each event includes its public page URL, but says nothing about ordering, result count, or how a soft-launched country affects the result beyond what the schema already states.
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?
A single well-formed sentence front-loads what the tool returns and appends the optional scoping. It earns its length, though the appositive about the lead row is slightly verbose.
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 simple read-only list tool with full schema coverage and no output schema, this is adequate but thin. Nothing tells the agent what a result looks like beyond a URL, and no usage guidance is offered against the three related sibling tools.
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%, and the country parameter's own description already explains the two-letter code and soft-launch behavior. The description only restates that the country is optional, adding no new syntax or semantics beyond the schema.
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 exactly what it returns (the featured events, same as the home page lead row) and adds the optional country scoping. This is specific enough to distinguish it from search-events and get-event.
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?
There is no explicit when-to-use guidance or named alternatives, but the 'same selection as the lead row of the home page' framing implies it is a curated, non-searchable list. The agent can infer it is for featured content rather than arbitrary queries, though nothing states when to prefer it over search-events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one public event by its sqid or slug (from search-events or featured-events): dates, venue, price, how to book or RSVP, organiser contact details shown on the event page, flying in (PPR, runway, landing fees and whether pilots can RSVP to fly in), the day's schedule and the description. Always share the event page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | The event sqid or slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, so safety is covered; the description adds real value by disclosing the payload contents (flying-in/PPR and landing fees, organiser contact, booking/RSVP method) that would otherwise be unknown since there is no output schema. It does not mention auth needs, rate limits, or not-found behavior.
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 sentences, front-loaded with the action and the identifier source, followed by a compact enumeration of returned fields. The enumeration is long but earns its place because no output schema exists to carry that information.
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 no output schema the description correctly takes on the job of describing return contents, and the 'Always share the event page URL' instruction covers a behavioral requirement annotations cannot express. It is nearly complete, only missing error/missing-event handling and confirmation that non-public events are excluded.
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 the single param is documented in the schema, but the description goes beyond it by stating where the sqid/slug originates (search-events or featured-events), which is actionable provenance the schema does not provide. That is meaningful added semantics over a one-parameter baseline of 3.
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?
Specific verb+resource ('Get one public event') plus an enumeration of exactly what the record contains, so an agent can distinguish it from search-events (multi-result) and featured-events (curated list). The parenthetical naming the source of the sqid/slug further separates it from its siblings.
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?
It implicitly sequences usage by saying the sqid/slug comes 'from search-events or featured-events', which tells the agent to search first and fetch details second. It does not state any explicit exclusion (e.g. private events) or a when-not-to-use case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The countries Events.Aero lists events in, with the code to pass to other tools and each country's public home and events pages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, so safety is covered. The description adds useful behavioral context absent from structured fields by describing what the response contains (country codes plus public home and events page references), which matters since no output schema exists.
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?
A single sentence with no filler, front-loading the resource and then the payload details. Slightly dense phrasing but every clause carries information.
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 simple, parameterless reference tool with no output schema, the description covers what is returned (countries, codes, page URLs) so an agent knows what it gets back. It could be marginally stronger by stating when to prefer it over the event-listing siblings.
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?
The tool takes zero parameters, so there is nothing for the description to clarify or compensate for. Baseline 4 applies for a parameterless tool.
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 names a concrete resource (countries Events.Aero lists events in) and the payload content (codes plus public home/events pages), which is specific enough to distinguish it from the event-oriented siblings. It is clear but never explicitly contrasts itself with siblings like list-event-types or search-events.
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?
It hints at usage by noting the code is 'to pass to other tools,' which implies this is a lookup/reference tool used before other calls. There is no explicit when-to-use statement or exclusion versus alternatives, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The kinds of aviation event on Events.Aero (airshow, fly-in, workshop and so on), with the value to pass to search-events and the public page that lists each type in a country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter country code for the browse links (default GB): list-countries lists the live countries; a soft-launched country can be named too |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context by disclosing what the payload contains (the search value plus a public page per country), which matters since there is no output schema. It stops short of mentioning caching, soft-launch caveats, or response size.
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?
A single sentence with the core resource front-loaded and the parenthetical examples kept brief; no padding or repetition. It is dense, packing three ideas (enumeration, search-events value, per-country page) into one clause chain, which slightly reduces readability.
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 simple read-only reference tool with one optional parameter fully documented in the schema, the description covers the essentials: what is enumerated and how the result is consumed. With no output schema, a little more on the shape of the returned entries (fields per type) would make it airtight.
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 the country parameter's default (GB) and list-countries relationship are fully documented in the schema itself. The description only alludes to the country dimension ('the public page ... in a country') without adding format or fallback detail beyond the schema, so the baseline 3 applies.
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?
Names the concrete resource (the kinds of aviation event on Events.Aero) and enumerates examples (airshow, fly-in, workshop), plus states what the result is useful for (the value to pass to search-events). The verb 'list' is carried by the name rather than the prose, but the resource and its relationship to search-events make it distinguishable from siblings.
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 use: this is the lookup that supplies the event-type value consumed by search-events, and the descriptor for the per-country browse pages. It names no explicit exclusions (e.g. 'do not call this for individual events'), so it falls short of the 5-level when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search upcoming public aviation events on Events.Aero (airshows, fly-ins, workshops and more). Filter by free text, event type, country, date range, distance from a point, free entry or online events. Results are ordered by start date, or by distance when latitude and longitude are given, one page at a time. Every result includes the public event page URL: send people there to book or RSVP.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest start date, YYYY-MM-DD, inclusive: a calendar date matched against each event's own local start date | |
| free | No | Only free events | |
| from | No | Earliest start date, YYYY-MM-DD: a calendar date matched against each event's own local start date (in the event's timezone) | |
| page | No | Page of results, from 1 | |
| type | No | Event type, from list-event-types | |
| query | No | Words matched against the event name, venue name, town and location: every word must appear, matched from the start of a word ("dux" finds Duxford); up to 100 characters | |
| online | No | Only online events | |
| country | No | Two-letter country code, e.g. GB: list-countries lists the live countries; a soft-launched country is answered only when named (without one, only live countries are searched) | |
| latitude | No | Search near this point (with longitude); results are ordered by distance | |
| per_page | No | Results per page (default 20, at most 50) | |
| longitude | No | Search near this point (with latitude) | |
| radius_nm | No | Radius around the point in nautical miles (default 50, at most 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and idempotentHint, and the description adds real behavior: results are ordered by start date (or by distance when coordinates are supplied), results are paginated 'one page at a time', and every result carries the public event page URL. It does not discuss rate limits or how soft-launched countries behave beyond what the schema says.
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 sentences, front-loaded with the purpose, then filters, then output ordering and the booking-URL affordance; no filler and no repetition of schema text.
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 no output schema, the description still tells the agent what comes back (ordered, paginated results containing the public event URL) and how to use it for booking, which is the key downstream action. For a 12-param read-only search whose parameters are fully schema-documented, nothing essential 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 description coverage is 100%, so each parameter — including date semantics, radius bounds, per_page limits and country soft-launch behavior — is already fully documented in the schema. The description's mention of ordering by distance when latitude/longitude are given largely duplicates the schema's own note, so it adds little beyond baseline.
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 and resource ('Search upcoming public aviation events on Events.Aero') and enumerates the filter dimensions (free text, type, country, date, distance, free, online), which is more than enough for an agent to distinguish it from featured-events and get-event.
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 makes clear this is the filtered-search entry point and points to list-event-types and list-countries for valid enum/country values, giving clear context for use. It stops short of stating when to prefer featured-events or get-event instead, so 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.
search-events1 field changedInput schema / properties / query / descriptionPrevious value: -"Free text matched against the event name, venue name, town and location (up to 100 characters)"New value: +"Words matched against the event name, venue name, town and location: every word must appear, matched from the start of a word (\"dux\" finds Duxford); up to 100 characters"search-events1 field changedInput schema / properties / type / enumPrevious value: -[
- "airshow",
- "fly_in",
- "static_display",
- "workshop",
- "seminar",
- "online_event",
- "club_meet",
- "conference",
- "expo",
- "competition",
- "charity_event",
- "military"
-]New value: +[
+ "airshow",
+ "fly_in",
+ "static_display",
+ "workshop",
+ "seminar",
+ "online_event",
+ "club_meet",
+ "conference",
+ "expo",
+ "competition",
+ "charity_event",
+ "military",
+ "spotting",
+ "model_aircraft"
+]search-events1 field changedInput schema / properties / type / enumPrevious value: -[
- "airshow",
- "fly_in",
- "static_display",
- "workshop",
- "seminar",
- "online_event",
- "club_meet",
- "conference",
- "expo",
- "competition",
- "charity_event"
-]New value: +[
+ "airshow",
+ "fly_in",
+ "static_display",
+ "workshop",
+ "seminar",
+ "online_event",
+ "club_meet",
+ "conference",
+ "expo",
+ "competition",
+ "charity_event",
+ "military"
+]featured-events1 field changedInput schema / properties / country / descriptionPrevious value: -"Two-letter country code from list-countries, e.g. GB"New value: +"Two-letter country code, e.g. GB: list-countries lists the live countries; a soft-launched country is answered only when named"list-event-types1 field changedInput schema / properties / country / descriptionPrevious value: -"Two-letter country code for the browse links (default GB)"New value: +"Two-letter country code for the browse links (default GB): list-countries lists the live countries; a soft-launched country can be named too"search-events1 field changedInput schema / properties / country / descriptionPrevious value: -"Two-letter country code from list-countries, e.g. GB"New value: +"Two-letter country code, e.g. GB: list-countries lists the live countries; a soft-launched country is answered only when named (without one, only live countries are searched)"featured-eventsget-eventlist-countrieslist-event-typessearch-eventsRead-only flight-training records for CFIs, students and schools: syllabus, schedule, FAR/AIM.
Read-only search of upcoming local events worldwide: music, comedy, AI/tech, arts, food, sports.
Search upcoming public events in Israel by date, city, region or category. Read-only; no API key.
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
Add one secure layer between your agents and this server.