Free fan-convention data for AI agents: dates, registration windows & table costs, US & Canada
Scored across 4 tools
Each tool has a distinct role: text/filter search, single-record profile fetch by slug, time-windowed registration listing, and a no-arg coverage/metadata lookup. The only mild overlap is that search_conventions already returns registration windows, so a 'which cons can I still apply to?' question could plausibly hit either search or list_open_registrations, but urgency sorting and the open/soon framing make the latter clearly the better fit.
All four tools share the artistally_ prefix and a predictable verb_noun pattern (get_convention, get_coverage, list_open_registrations, search_conventions) in consistent snake_case. Verb choice also maps sensibly to cardinality: singular get for one record, list/search for collections.
Four tools is on the lean side but each earns its place: search for discovery, get for depth, list for time-sensitive lookups, coverage for valid filter values. No redundant or vestigial endpoints, though the surface is small enough that one more convenience tool would not feel excessive.
As a read-only convention-data API the lifecycle is well covered: discovery, detail (pricing, history, policies), open-registration tracking, and filter-value metadata. Minor gaps remain — no tool enumerates valid community values (only regions/states/metros via get_coverage) and there is no direct lookup-by-URL path, forcing agents to derive slugs from search results.
Full profile of one convention by slug: dates, venue and address, website, artist-alley and vendor registration windows/costs/URLs, every published price tier (artist spaces, dealer booths, badges; this edition and past ones) with its source, portfolio and table-share policy, hotel block, transit access, organizer verification, and up to 6 years of attendance/pricing history. Get slugs from artistally_search_conventions or an ArtistAlly event URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Convention slug, e.g. "otafest" — the last segment of an ArtistAlly /events/ URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, closed-world lookup, so the bar is lower. The description adds substantial value beyond that by disclosing the return surface (provenance for price tiers, verification status, six-year history cap) that annotations do not cover, though it says nothing about error behavior for unknown slugs.
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 core purpose is front-loaded and the routing hint is placed last, which is effective. The long enumeration of return fields is dense but earns its space 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 does the heavy lifting by enumerating the return contents thoroughly, including history depth and source attribution. It is nearly complete for a read lookup, missing only not-found or error behavior.
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?
Only one parameter exists and the schema description coverage is 100%, so the schema already fully documents the slug format and provenance. The description's note that slugs come from search or an event URL is useful but largely restates the schema's own example.
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 ('Full profile of one convention by slug') and then enumerates exactly which fields are included, so an agent can distinguish it from the search or coverage siblings without opening a 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?
Explicitly routes the agent to artistally_search_conventions or an ArtistAlly event URL for slugs, giving clear context for when this tool applies. It stops short of stating exclusions (e.g., when to prefer coverage or list_open_registrations), so it is not a full when/when-not treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The regions, states/provinces, and metro areas ArtistAlly tracks, with approved-convention counts. Use it to learn valid region/state/metro filter values for the other tools. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does so by disclosing the return content (counts of approved conventions) and confirming the call is argument-free, which is useful preparatory information for an agent building a filter call.
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, the second gives the actionable usage. No filler, and the most decision-relevant information comes first.
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 must carry the return-value burden, and it names the key fields (regions, states/provinces, metros, approved-convention counts). It doesn't describe the response structure (flat list vs. nested by region), leaving a small gap for a lookup tool.
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 the baseline is 4. The description reinforces this with 'Takes no arguments,' eliminating any doubt an agent might have about optional filters.
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?
Identifies the exact resource returned: regions, states/provinces, and metro areas tracked by ArtistAlly, with approved-convention counts. This is immediately distinguishable from the sibling tools (get_convention, search_conventions, list_open_registrations), which operate on individual conventions rather than the coverage map.
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?
Explicitly states the use case: 'Use it to learn valid region/state/metro filter values for the other tools,' which tells the agent to call this before filtering elsewhere. It stops short of naming a specific sibling or describing when it can be skipped, keeping it at a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Artist-alley and vendor/dealer registration windows that are open right now or opening soon, sorted by urgency (soonest close date first). The go-to tool for questions like "which cons can I still apply to?" or "what artist alleys open this month?".
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Which registration kind to include. Default: both. | |
| limit | No | Max entries per section, default 30. | |
| state | No | Two-letter US state or Canadian province code, e.g. "GA", "TX", "ON". | |
| region | No | Coverage region, e.g. "Southeast", "Midwest", "West Coast", "Canada". Valid values come from artistally_get_coverage. | |
| community | No | Filter by community: furry, anime, gaming, or multi (multi-genre). | |
| within_days | No | Look-ahead window in days for "opening soon". Default 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds temporal scoping (open right now/opening soon) and ordering (soonest close date first), which are useful beyond annotations, but it does not describe output sections or pagination.
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 compact sentences, front-loaded with the resource and scope, then use-case examples. The "go-to" phrasing is mildly promotional but still earns its place by signaling intended use.
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 six-filter list tool with no output schema, the description covers purpose, temporal boundary, use cases, and sort order. It leaves return shape and the per-section behavior implied by "limit" undocumented, so an agent gets the call but not the full result model.
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%, so all six filters—type, state, region, community, within_days, limit—are already documented. The description only indirectly echoes type and within_days and adds no syntax or default details 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?
The description names a specific resource—artist-alley and vendor/dealer registration windows—and narrows scope to windows open now or opening soon, with a sort order. It is clear enough to distinguish from a general convention lookup, though it does not explicitly name the sibling tools it is not.
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 supplies concrete use cases ("which cons can I still apply to?", "what artist alleys open this month?") and calls itself the go-to tool for them. It stops short of stating when not to use it or naming alternatives such as search_conventions or get_convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search fan conventions (furry, anime, gaming) across 51 US and Canadian metro areas. Returns upcoming conventions by default (soonest first); set include_past to search the archive too. Filter by text, community, region, state, metro, or date range. Returns dates, venue, location, registration windows and table costs, plus a canonical ArtistAlly URL per convention.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20. | |
| metro | No | Metro slug from artistally_get_coverage, e.g. "atlanta", "toronto". | |
| query | No | Free-text match on convention name, venue, or city, e.g. "Otafest" or "Atlanta". | |
| state | No | Two-letter US state or Canadian province code, e.g. "GA", "TX", "ON". | |
| offset | No | Pagination offset, default 0. | |
| region | No | Coverage region, e.g. "Southeast", "Midwest", "West Coast", "Canada". Valid values come from artistally_get_coverage. | |
| community | No | Filter by community: furry, anime, gaming, or multi (multi-genre). | |
| include_past | No | Include conventions that have already finished (default false). Past results are still sorted soonest-first; use starts_after/starts_before to target a specific year. | |
| starts_after | No | Only conventions starting on or after this date (YYYY-MM-DD). | |
| starts_before | No | Only conventions starting on or before this date (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare that this is a read-only, idempotent, non-destructive, closed-world operation, and the description adds useful behavioral context: default sorting, archive behavior, and the kinds of fields returned. It does not discuss authentication, rate limits, or pagination behavior, but those are less critical given the explicit annotations.
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 compact and front-loaded: the search scope and default behavior come first, followed by filtering and return-value details. Every sentence contributes useful information without repetition or 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?
Although there is no output schema, the description summarizes the return payload (dates, venue, location, registration windows, table costs, canonical URL), which is exactly what an agent needs to know. Combined with the rich schema and annotations, the definition is complete for correct tool selection and invocation.
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 ten parameters are already documented in detail, including defaults, formats, and examples. The description restates the available filter categories and include_past behavior but adds little syntax or semantic detail beyond what the schema already provides.
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 verb and resource: search fan conventions across 51 US and Canadian metro areas, with clear scope and supported communities. It does not explicitly distinguish this search tool from sibling tools such as artistally_get_convention or artistally_list_open_registrations, so it falls short of a 5.
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 clearly explains default behavior (upcoming conventions, soonest first) and how to include past events via include_past. It also enumerates the available filter dimensions, but it does not name alternatives or explicitly say when to prefer this tool over the sibling lookup or registration-list tools.
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.
artistally_search_conventions1 field changedInput schema / properties / include_pastAdded value: +{
+ "description": "Include conventions that have already finished (default false). Past results are still sorted soonest-first; use starts_after/starts_before to target a specific year.",
+ "type": "boolean"
+}artistally_get_conventionartistally_get_coverageartistally_list_open_registrationsartistally_search_conventionsMICE data for AI agents: trade shows, exhibitors, organizers, venues, halls, subsidies. Asia-first.
US public data for AI agents: recalls, gov contracts, IRS ZIP income, TX leads, WHOIS, tech stack
Parsed public-domain market data for AI agents, priced below DIY inference cost, paid via x402.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Add one secure layer between your agents and this server.