MICE data for AI agents: trade shows, exhibitors, organizers, venues, halls, subsidies. Asia-first.
Scored across 3 tools
get_event (single series detail), search_events (series search by name/country/vertical) and upcoming_events (editions in a date window) are mostly distinct, and the description explicitly reserves upcoming_events for 'what shows are on' queries. Still, a country-filtered query could plausibly land on either search_events or upcoming_events, so there is minor overlap.
get_event and search_events follow a clean verb_noun pattern, but upcoming_events uses an adjective_noun form instead. The deviation is small and the names remain predictable and readable.
Three tools is thin for a domain spanning event series, editions, exhibitors, venues and organizers. Read-only search surfaces often get away with few tools, but this set leaves little room for the sub-resource lookups it hints at.
get_event tells the agent to 'use an edition id with list_edition_exhibitors', but no such tool exists in this set, creating a dead end. There is also no way to fetch edition details, venues, organizers or exhibitors, so core follow-up paths are missing.
Requires a free Messe Atlas account (sign in when prompted). Checks an exhibition floor plan against published default safety and layout limits — no AI, deterministic: stand overlaps, keep-clear gangways, fire-point halos, 4 m entrance strips, rows ≤ 30 m, gangways ≥ 3 m, travel distance ≤ 61 m, dead ends ≤ 18 m, stand area ≤ 2 × gangway area, exit width at 5 mm per person, gate lines, power pits. Coordinates in metres, origin at the hall's north-west corner, x east, y south. plan is either the short form {hall: {w, l} (or space_id), exits: [{id, kind: public|fire|folding|service|open, a: [x,y], b: [x,y]}], stands: [{id, x, y, w, d, door_side?: n|e|s|w}] (x, y = the stand's north-west corner), features?: [{id, x, y, w, d}], peak_people} or the full L2 plan dict (hall|site, exits, units, solids, keep, fire, peak). space_id (from get_venue_spaces) supplies the hall only when Atlas holds its outline; otherwise send the hall inline. Returns ok, every check with rule, value, limit and source, a summary (stands, m² sold, gangway m², ratio), limits_status, a preview_url (SVG, 24 hours) and a disclaimer. Convex polygons only; at most 2,000 objects and 160,000 m². Free accounts get 3 successful checks a month, Pro 30, Team and Enterprise unlimited; invalid plans are not counted.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | The short form (stands, exits, hall or space_id, features, peak_people) or the full L2 plan dict (hall|site, exits, units, solids, keep, fire, peak). Metres; origin north-west; at most 512 KB of JSON. | |
| space_id | No | Venue space id or slug from get_venue_spaces / search_venue_spaces (short form only). Used for the hall only when its geometry_status is outline or better. | |
| confirmed_only | No | Leave out exits listed in the plan's pending_exits (awaiting the venue's confirmation). |
Requires a free Messe Atlas account (sign in when prompted). Without country: the top 20 countries by events. With country: events, editions, organizers, venues, companies and speakers counted for that country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Requires a Pro plan. Every edition one company exhibited at or sponsored, newest first (20 per page): event, year, dates, city, country, tier, booths and the edition's as_of. Filter by role and year range; pass cursor from the previous answer for the next page. history_truncated is set for very large histories.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Only exhibitor or sponsor records. Defaults to both. | any |
| cursor | No | Opaque cursor from the previous page's `next_cursor`. | |
| company | Yes | Company slug or uuid, as returned by search_companies. | |
| to_year | No | Latest edition year (inclusive). | |
| from_year | No | Earliest edition year (inclusive). |
Requires a Pro plan. Writes a CSV to your workspace's exports and returns a download link that works for 24 hours without signing in. Sources: edition_exhibitors (an edition's exhibitors, 1,000 rows per part; pass next_cursor back as cursor for the next part), edition_sponsors (up to 200), prospects (the find_prospects arguments, up to 1,000 companies), and reveals (Team plan and up: the people your workspace revealed, with the email and phone it revealed, 500 per part; not offered when the workspace keeps contacts out of AI conversations). Rows count against your plan's daily export allowance; the answer shows what is left. Needs the 'atlas.reveal' permission and a personal connection.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | `next_cursor` from the previous part (edition_exhibitors, reveals). | |
| source | Yes | What to export. | |
| prospects | No | The find_prospects arguments (source prospects). | |
| edition_id | No | Edition uuid from get_event (edition_exhibitors, edition_sponsors). |
Requires a Pro plan. Prospect lists: companies at any include edition and at none of the exclude editions ("at A or B, not at C"), most editions attended first, then most recent (20 per page). A side is an event (slug or uuid, optional years; default its latest 5 past editions) or an edition_id; at most 5 editions per side; oversized editions are refused as too_broad. Optional HQ country and role. Returns company, hits, last edition and url, total_about, and editions_used with each edition's as_of.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | "exhibitor" ignores sponsor lists. Defaults to both. | any |
| cursor | No | Opaque cursor from the previous page's `next_cursor` (only valid with the same arguments). | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). | |
| exclude | No | Editions to rule out: companies at any of these are dropped. | |
| include | Yes | Editions the companies attended (any of them). |
Requires a free Messe Atlas account (sign in when prompted). Convention-bureau and tourism-board support schemes for an exhibition, conference, meeting or incentive (optionally in one country). Each active scheme is screened against its published criteria: match is likely (every published criterion supplied and met) or check (something is unknown, late or stale), with the reasons; schemes that do not appear to fit are listed under not_matched with the reason. Returns benefits and amounts as published, url, apply_url, as_of and stale. Not advice: confirm eligibility, amounts and deadlines with the body.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). | |
| attendees | No | Expected attendees (delegates / participants / visitors). | |
| event_type | Yes | What kind of event. | |
| start_date | No | Event start (YYYY-MM-DD), to screen application lead times. | |
| international_pct | No | Expected share of international participants, in percent. |
Requires a free Messe Atlas account (sign in when prompted). One company by slug or uuid: description, tags, parent, subsidiaries, sponsorships, total editions, last seen date.
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid, as returned by the search tools. |
One event series by slug or uuid with organizer, venue, tags and every edition (ids, dates, exhibitor / sponsor / speaker / country counts). Use an edition id with list_edition_exhibitors.
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid, as returned by the search tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that by disclosing the breadth of the returned payload (nested organizer/venue/tags and per-edition counts), which matters because there is no output schema. It does not mention errors (e.g., not-found on a bad slug) or auth needs.
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 front-loaded sentence with the resource first and the payload enumeration after; the trailing cross-tool pointer is separated cleanly. Slightly list-dense, but 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 no output schema and only one required param, the description carries return-shape information and does it well by naming the included sub-objects and the per-edition counts. It stops short of stating error behavior or whether the response is a single object, but it is adequate for a simple id lookup.
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 parameter already documents itself as 'Slug or uuid, as returned by the search tools.' The description only restates slug-or-uuid acceptance and adds no format or source 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?
The description states a specific resource ('One event series') retrieved by a specific key ('by slug or uuid') and enumerates the payload: organizer, venue, tags, editions with counts. That makes the id-lookup nature clear, distinct in practice from search_events / upcoming_events, though neither sibling is named explicitly.
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 gives one concrete usage path ('Use an edition id with list_edition_exhibitors') but never says when to call this vs. search_events or upcoming_events, nor that it accepts an already-known slug/uuid. Usage is only implied by the 'by slug or uuid' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requires a free Messe Atlas account (sign in when prompted). One organizer by slug or uuid with description, parent company and its top event series.
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid, as returned by the search tools. |
Requires a free Messe Atlas account (sign in when prompted). One speaker by slug or uuid with bio and the sessions they spoke at (event, edition, year, session title).
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid, as returned by the search tools. |
Requires a free Messe Atlas account (sign in when prompted). One venue by slug or uuid with city, website, the event series it hosts and its upcoming editions (next 20).
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid, as returned by the search tools. |
Requires a free Messe Atlas account (sign in when prompted). The halls and rooms of one venue (slug or uuid from search_venues): kind, level, area m², width, length, clear height, floor load, column-free, capacities (theatre, classroom, banquet, cocktail, 3×3 booths), doors, utilities, notes, and each row's source_url and as_of (stale when older than 180 days). A null figure is not published by the venue. Drawings are not served; geometry_status says whether Atlas holds an outline.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue slug or uuid from search_venues / get_venue. |
Requires a free Messe Atlas account (sign in when prompted). Exhibitors at one edition (20 per page): exhibitor name, booth, pavilion country, tier and the matched canonical company when known. Free accounts see the first 20 rows plus how many more exist.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page, 20 rows each. | |
| edition_id | Yes | Edition uuid from get_event. |
Requires a Pro plan. Sponsors of one edition (20 per page, up to 200, highest tier first): company, public tier label, HQ country and url, with the edition's as_of (sponsor lists refresh at the full publish). Takes an edition id from get_event.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page, 20 rows each. | |
| edition_id | Yes | Edition uuid from get_event. |
Requires a free Messe Atlas account (sign in when prompted). Without kind: the leaderboard kinds available. With kind: the ranked rows (rank, name, value, slug) for that board.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | A kind from the list, e.g. top_exhibitors_5y. |
Requires a free Messe Atlas account (sign in when prompted). Your workspace's "AI watches": what is watched (type, id, name), how many of your plan's watches are used, the next digest date and the alert channels (email digest; webhooks on the Team plan and up).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Requires a free Messe Atlas account (sign in when prompted). Search canonical companies by name (full-text, best 200 matches), optionally filtered by HQ country. Without q: most active first (large countries continue A–Z after two pages; each answer says its order and max_page). Returns id, slug, name, kind, domain, HQ, industry, size band and editions in the last five years.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text phrase matched on the company name and domain. | |
| page | No | 1-based page, 20 rows each. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Search event series by name, country or vertical. Each row carries edition count, last and next start dates and the largest captured exhibitor count.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text phrase matched on the event name. | |
| page | No | 1-based page, 20 rows each. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). | |
| vertical | No | Vertical slug (composites, mice, …). |
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 value by disclosing what each returned row contains (edition count, last/next start dates, largest exhibitor count) — useful behavior beyond the annotations, especially with no output 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?
Two tight sentences: the first front-loads what can be searched, the second front-loads what comes back. No filler or redundancy.
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 and a simple 4-param read tool, the description covers the search dimensions and the row shape well. It omits any note on result limits or how to page through beyond what the schema specifies, a minor gap.
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 every parameter (q, page, country, vertical) is already documented with format, pattern and range. The description only restates the filter dimensions (name, country, vertical) without adding syntax or matching semantics, 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?
States a specific verb (Search) and resource (event series) plus the three filter axes — name, country, vertical. An agent can identify it as the text/geo lookup entry point, though it never names the sibling tools (get_event, upcoming_events) it differs from.
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?
Usage is only implied by the phrase 'Search event series by name, country or vertical'; there is no explicit when-to-use, when-not, or routing to get_event for a single record. Siblings exist but are never referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requires a free Messe Atlas account (sign in when prompted). Event organizers by name and/or country with the number of event series they run.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text phrase matched on the organizer name. | |
| page | No | 1-based page, 20 rows each. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Requires a free Messe Atlas account (sign in when prompted). People on the public record as speakers, by name prefix (≥ 2 letters) and/or country. Never returns email or phone.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name prefix (at least two letters). | |
| page | No | 1-based page, 20 rows each. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Requires a free Messe Atlas account (sign in when prompted). Venues by name prefix and/or country, most event series hosted first, with the number of series each hosts. q matches the start of the venue name ("impact", "marina bay", "bitec"), case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Start of the venue name (case-insensitive prefix, first 100 matches). | |
| page | No | 1-based page, 20 rows each. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Requires a free Messe Atlas account (sign in when prompted). Halls and rooms in a country that meet a size: optional city, minimum area (m²), minimum clear height (m) and a minimum capacity of one kind (theatre, classroom, banquet, cocktail, booths_3x3). Best fit first (the smallest published area that meets the filters), 20 per page with next_cursor. Each row has the venue, the fit reasons, waste_pct, source_url, as_of and stale. Spaces that do not publish a filtered figure are left out.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City (case-insensitive exact match, e.g. Bangkok). | |
| cursor | No | Opaque cursor from the previous page's `next_cursor` (only valid with the same arguments). | |
| country | Yes | ISO-3166 alpha-2 (TH, DE, JP …). | |
| min_area_sqm | No | Minimum floor area in square metres. | |
| min_capacity | No | Minimum capacity for capacity_kind. | |
| capacity_kind | No | Capacity layout; use with min_capacity. | |
| min_clear_height_m | No | Minimum clear (ceiling) height in metres. |
Requires a free Messe Atlas account (sign in when prompted). Search companies and events by meaning rather than keywords ("flame-retardant composites suppliers", "cannabis trade shows in Asia"). Returns the closest matches with a similarity score. Use search_* for exact names.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Defaults to both. | |
| query | Yes | What you are looking for, in plain words. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). |
Requires a free Messe Atlas account (sign in when prompted). Removes one item from your workspace's "AI watches" (entity_type and id as list_watches shows them). Removing something not watched changes nothing. Needs the 'atlas.reveal' permission.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id as list_watches shows it. | |
| entity_type | Yes | Type as list_watches shows it. |
Trade-show and exhibition editions starting in a date window, soonest first, optionally filtered by country, vertical or venue. Each row has event, dates, city, country, venue, organizer, source_url and as_of. Use this for 'what shows are on in …' questions; pass cursor from the previous answer for the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the window (YYYY-MM-DD), at most 24 months after today. Defaults to from + 12 months. | |
| from | No | Start of the window (YYYY-MM-DD). Defaults to today. | |
| venue | No | Venue slug or uuid from search_venues. | |
| cursor | No | Opaque cursor from the previous page's `next_cursor`. | |
| country | No | ISO-3166 alpha-2 (TH, DE, JP …). | |
| vertical | No | Vertical slug (composites, mice, …). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that, the description discloses sort order (soonest first) and pagination mechanics via cursor, which are genuine behavioral traits the annotations don't carry.
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 tight sentences: the first front-loads what is returned and how it is ordered/filtered, the second gives usage and paging. No filler or restatement of the title.
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 usefully enumerates the row fields (event, dates, city, country, venue, organizer, source_url, as_of) and explains pagination, which is what an agent needs. Minor gap: it doesn't state whether results are capped or how empty windows behave, but the definition is otherwise self-sufficient.
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 all six parameters (including defaulting rules for from/to and the origin of venue/cursor values) are already documented in the schema. The description only adds the cursor-paging hint, which is already implied by the schema's 'opaque cursor from the previous page'. Baseline 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+resource: trade-show/exhibition editions within a date window, returned soonest-first, with optional country/vertical/venue filters. The combination of date-window scoping, sort order, and filter dimensions makes it clearly distinct from get_event and 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?
Gives an explicit triggering context ('what shows are on in …' questions) and instructs how to page by passing the previous answer's cursor. It does not explicitly say when to prefer get_event or search_events over this tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requires a free Messe Atlas account (sign in when prompted). Adds an event, edition, company, organizer, country (ISO code) or vertical (slug) to your workspace's "AI watches" list. Changes (new editions, new exhibitors or sponsors, speakers announced, score changes) arrive in the weekly email digest, and as signed webhooks on the Team plan and up. Watching the same thing twice changes nothing. Free plans watch 1 item, Pro 100, Team and Enterprise 500. Needs the 'atlas.reveal' permission.
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Slug or uuid from the search / get tools; an edition uuid from get_event; an ISO-3166 alpha-2 code for a country; a vertical slug. | |
| entity_type | Yes | What to watch. |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_floorplancountry_totalsexhibitor_historyexport_listfind_prospectsfind_subsidiesget_companyget_organizerget_speakerget_venueget_venue_spaceslist_edition_exhibitorslist_edition_sponsorslist_leaderboardslist_watchessearch_companiessearch_organizerssearch_speakerssearch_venue_spacessearch_venuessemantic_searchunwatchwatchget_eventsearch_eventsupcoming_eventsTravel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Verified local business registry for AI agents. Currently serving Malaysia.
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
Add one secure layer between your agents and this server.
