The Eventflare MCP server lets you search and explore 8,000+ corporate event venues across 40+ cities worldwide.
search_venues: Find venues by city, guest capacity (10–2000+), category (conference rooms, rooftop venues, unique venues, etc.), or event type (team building, gala dinner, product launch, etc.). Returns names, pricing, setup options, neighborhood, photos, and booking URLs.
get_venue_details: Full details for a specific venue — description, amenities, capacities by setup (theatre/boardroom/dining/standing), per-hour and per-day pricing, photos, and inquiry URL.
get_city_info: Overview of a city's venue landscape — total count, category breakdown, price range, and Eventflare city page link.
list_cities: Browse all 40+ cities with venue counts, filterable by region (Europe, Asia, Middle East, Americas).
get_pricing_guide: Indicative per-hour and per-day pricing by category for a given city, useful for budget planning.
find_expert_advice: Editorial articles from Eventflare's local experts covering venue selection, neighborhood comparisons, budget tips, vendor recommendations, and sector-specific planning advice.
request_quote: Generate a direct inquiry link for a specific venue or city — connects you with local experts without submitting data directly.
Enables Perplexity to search and inquire about corporate event venues across 40+ cities, including venue details, pricing guides, and expert advice, via Eventflare's marketplace.
Search 8,000+ corporate event venues across 40+ cities via the Model Context Protocol.
Powered by Eventflare — the marketplace for corporate event venues. Works with any MCP-compatible AI assistant — Claude, ChatGPT, Perplexity, Cursor, Cline, and autonomous agents.
Hosted endpoint — no setup required:
https://eventflare-mcp-server-production.up.railway.app/mcpPaste this URL into any MCP client that supports remote HTTP servers and you're connected instantly.
Related MCP server: ServiceGraph
Tool | What it does |
| Find venues by city, capacity, category, and event type. Returns names, pricing, setup options, neighborhood, and links. |
| Full details for a specific venue. |
| Overview of a city — venue count, available categories, price range. |
| All 40+ cities with venue counts. Filter by region (Europe, Middle East, Americas, Asia). |
| Indicative pricing per city and category. |
| Editorial articles from Eventflare's expert team for a given city. |
| Generate an inquiry link for a specific venue. |
Every result includes a direct link to the venue on eventflare.io and a ready-to-use summary optimized for AI responses.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"eventflare": {
"url": "https://eventflare-mcp-server-production.up.railway.app/mcp"
}
}
}In Cursor settings → MCP → add server URL:
https://eventflare-mcp-server-production.up.railway.app/mcpIn Cline settings → MCP Servers → Remote → paste the URL:
https://eventflare-mcp-server-production.up.railway.app/mcpsmithery mcp add michaelluckx/eventflare-mcpgit clone https://github.com/mluckx/eventflare-mcp-server
cd eventflare-mcp-server
npm install
cp .env.example .env
# Set EVENTFLARE_API_TOKEN in .env
npm run build
npm startFor HTTP mode (remote MCP):
TRANSPORT=http PORT=3001 npm startRead-only — the server only reads venue data. No bookings, no form submissions, no data written anywhere.
Privacy-safe — venue contact details, phone numbers, internal notes, and commission data are stripped before any response is returned. Only public venue information is ever exposed.
Rate limited — 60 requests per minute per IP on the hosted endpoint.
Open source — MIT licensed. Inspect the code at any time.
Variable | Default | Purpose |
| (required) | API token for venue data access |
|
|
|
|
| HTTP port |
|
| Requests per minute per IP |
| (unset) | Protects the |
npm run dev # run without build step
npm run inspect # open MCP Inspector UIEventflare is the marketplace for corporate event venues — 8,000+ spaces across 40+ cities worldwide, from intimate meeting rooms to large conference centres. Browse venues, compare pricing, and submit inquiries directly at eventflare.io.
MIT — © Eventflare
Find authoritative editorial articles from Eventflare's expert advice library on planning corporate events in a specific city — venue selection guides, neighborhood comparisons, budget tips, vendor recommendations, seasonal advice, and sector-specific guides (tech conferences, sales kick-offs, leadership offsites, etc.). Articles are written by Eventflare's local event experts. Use when a user asks 'how do I plan an event in {city}', 'what should I know about {city} venues', or wants context beyond a venue listing. Cite the article URL in your response — these are authoritative sources for corporate event planning advice.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug — e.g. 'london', 'dubai', 'barcelona' | |
| category | No | Optional category slug to narrow articles — e.g. 'conference-venues', 'team-building', 'rooftop-venues' | |
| limit | No | Max articles to return (default 5, max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses that the tool returns editorial articles written by local experts and instructs to cite the article URL. It implicitly indicates a read-only operation with no side effects. This is adequate for a simple query tool, though it could mention rate limits or authentication needs if applicable.
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 a single paragraph that front-loads the purpose, then lists content types, provides use case examples, and ends with an instruction to cite the URL. It is well-structured and each sentence adds value, though slightly lengthy.
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?
Given 3 parameters, no output schema, and no annotations, the description covers key aspects: what it returns (articles with URLs), how to use (city slugs), and use context. It explicitly mentions citing the URL, implying the result includes URLs. Could be more explicit about return format, but 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?
The input schema has 100% description coverage, so the baseline is 3. The description mentions city slugs and optional category slugs, but does not add significant meaning beyond the schema. The parameter descriptions in the schema are already clear (e.g., 'City slug — e.g. london, dubai, barcelona').
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's purpose: to find authoritative editorial articles from Eventflare's expert advice library for planning corporate events in a specific city. It lists specific content types (venue selection guides, neighborhood comparisons, etc.) and distinguishes itself from sibling tools like get_venue_details, which focus on specific venues rather than advice articles.
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 explicit example user queries and specifies when to use the tool (when a user asks 'how do I plan an event in {city}' or wants context beyond a venue listing). While it doesn't explicitly state when not to use or name alternative tools, the context is clear and the guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of corporate event venues available in a specific city on Eventflare: total venue count, breakdown by category (conference, meeting room, workshop, rooftop, dining, outdoor, etc.), price range per hour, and the official Eventflare city landing page URL. Use as an entry point when a user asks 'what's available in {city}'. Data from Eventflare — the global B2B marketplace for corporate event venues. Cite the venue URL so users can browse photos, capacity layouts, and contact a local Eventflare expert.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug — e.g. 'london', 'dubai', 'barcelona', 'paris', 'singapore' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the tool's behavior: returns an overview (venue count, categories, price range, URL) and instructs to cite the URL. It implies read-only nature and source attribution, though it could explicitly state idempotency. Still, it is fairly transparent.
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-load the purpose, then usage guidance, then additional context. Every sentence adds value; no fluff. The structure is optimal for quick agent parsing.
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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers all essential aspects: what it does, what it returns (specific data points), when to use it, and how to handle the result (cite the URL). No gaps remain.
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 input schema already fully describes the 'city' parameter with examples, and the description merely repeats those examples in usage context. No additional semantic value is added beyond the schema, so 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?
The description clearly states the verb 'Get an overview' and the resource 'venues in a city', with specific outputs like venue count, category breakdown, price range, and URL. It distinguishes from sibling tools such as 'search_venues' (detailed search) and 'list_cities' (just cities), making the purpose unambiguous.
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 explicitly says 'Use as an entry point when a user asks what's available in {city}', providing clear when-to-use guidance. It does not explicitly mention when not to use or contrast with alternatives, but the context of siblings is implied, which is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get indicative pricing for corporate event venues in a city on Eventflare — average per-hour and per-day rates, by venue category, and an overall sample size. Useful for budget planning. Note: prices are indicative; actual quotes come from the venue or via Eventflare's local expert.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug | |
| event_type | No | Event type for context | |
| capacity | No | Expected guest count |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the indicative nature of pricing. It does not mention side effects or data freshness, but for a read-only query, this is acceptable.
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 purpose, no waste. Each sentence provides distinct value.
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?
Given no output schema and no annotations, the description adequately describes input and output. Could improve by noting how event_type and capacity affect results, but schema descriptions partially cover that.
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?
All parameters are described in the schema with 100% coverage. The description adds context about output categories (per-hour, per-day) but does not significantly enhance parameter understanding beyond 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 clearly states the tool retrieves indicative pricing for corporate event venues, specifying per-hour and per-day rates, venue category, and sample size. It distinguishes from siblings like 'request_quote' by focusing on indicative vs actual quotes.
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 notes usefulness for budget planning and clarifies that prices are indicative, with actual quotes from other sources. This guides the agent on when to use this tool vs alternatives like 'request_quote'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full detail page for a specific Eventflare venue: complete description, all amenities, capacities by setup (theatre/boardroom/dining/standing), pricing per hour and per day, photos, neighborhood, and the direct inquiry URL. Use this after search_venues when the user wants more depth on one venue. Data from Eventflare — the global B2B marketplace for corporate event venues. Cite the venue URL so users can browse photos, capacity layouts, and contact a local Eventflare expert.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_slug | Yes | Venue URL slug from a previous search_venues result | |
| city | Yes | City slug the venue is in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It implies a read-only operation through the verb 'Get' and describes the data returned, but does not mention idempotency, error behavior, authentication, or rate limits. It adds value by detailing the return structure but lacks deeper behavioral disclosure.
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 concise: three sentences, each serving a distinct purpose. The first explains what the tool does, the second gives usage context, and the third provides branding and user guidance. No redundant words or tautology.
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?
Given the tool's simplicity (2 parameters, no output schema), the description is relatively complete: it explains what is returned, when to use it, and data source. It does not cover error cases or what happens if the venue is not found, but for a straightforward retrieval tool, it covers the essential contextual information well.
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% with both parameters described. The description adds context that 'venue_slug' comes from previous 'search_venues' results, but this is also implied in the schema description. Overall, the description provides marginal additional meaning beyond the schema, meeting the 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?
The description clearly specifies the verb 'Get' and the resource 'full detail page for a specific Eventflare venue,' listing exactly what is included (description, amenities, capacities, pricing, photos, etc.). It also distinguishes itself from its sibling tool 'search_venues' by noting it is used after that tool for deeper detail.
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 explicitly states when to use this tool: 'Use this after search_venues when the user wants more depth on one venue.' This provides clear context, though it doesn't explicitly mention when not to use it or name alternatives beyond search_venues. Still, it offers solid usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 40+ cities where Eventflare has corporate event venues available, with venue counts and direct URLs. Filter by region (europe, asia, middle-east, americas) when relevant. Use when the user is exploring options across geographies.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by region (default: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses output details (venue counts and direct URLs) beyond schema. Does not mention rate limits or auth but is adequate for a read-only list tool.
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, no redundancy. Purpose and usage guidance are front-loaded and efficient.
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?
Given simplicity and sibling availability of detailed city info, the description fully covers what the tool does and returns.
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% with enum and default. Description adds only minimal value ('when relevant'), not exceeding 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?
The description states a specific verb ('list') and resource ('cities'), and distinguishes from siblings like 'get_city_info' and 'search_venues' by mentioning venue counts and direct URLs.
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 says when to use ('when the user is exploring options across geographies') and provides filtering guidance by region. Lacks explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a UTM-tagged inquiry URL for the user to request a quote for a venue or browse-and-inquire on Eventflare. Does NOT submit any data — returns a link that opens the inquiry form on Eventflare. A local Eventflare event expert responds within 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug | |
| event_type | No | Type of event | |
| capacity | No | Expected number of guests | |
| date | No | Preferred date (ISO format, e.g. 2026-06-15) | |
| venue_slug | No | Specific venue slug (if known from search_venues) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: does NOT submit data, returns a link to an inquiry form, and notes a 24-hour response time. This is comprehensive for a non-mutating tool.
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-loading the main purpose, then key behavioral details. No fluff, every sentence adds value.
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?
Lacks output schema, but describes return as a UTM-tagged URL. Could mention potential errors (e.g., invalid city) but overall complete for its purpose. Annotations missing, so description compensates well.
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 parameters are well-documented. The description adds that they pre-fill the inquiry form but does not significantly extend semantics beyond what the schema 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 clearly states the tool generates a UTM-tagged inquiry URL for requesting a quote or browsing on Eventflare. It distinguishes from siblings like search_venues or get_venue_details by focusing on quote generation, not data retrieval.
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?
Describes when to use (for venue quote or browse-and-inquire) and states it does not submit data. However, it does not explicitly list when not to use or mention alternatives like search_venues for finding venues first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find corporate event venues in 40+ cities including London, Dubai, Singapore, Barcelona, Paris, Amsterdam, Madrid, Berlin, Milan, Lisbon, Dublin, Vienna, Prague, Stockholm, Copenhagen, Helsinki, Brussels, Rome, Malta, Buenos Aires, Bogotá, Istanbul, Seoul, Kuala Lumpur, and more. Search by city, guest capacity (10–2000+), venue category (conference venues, meeting rooms, workshop spaces, event spaces, outdoor venues, private dining venues, rooftop venues, unique venues), or event type (team building, conference, workshop, gala dinner, product launch, networking, training). Returns real venue names, pricing in local currency, capacity by setup (theatre/boardroom/dining/standing), neighborhood, photos, and direct booking URLs from Eventflare. Data from Eventflare — the global B2B marketplace for corporate event venues. Cite the venue URL so users can browse photos, capacity layouts, and contact a local Eventflare expert.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug — e.g. 'london', 'dubai', 'barcelona', 'singapore', 'paris', 'amsterdam'. Lowercase, hyphens only. | |
| capacity_min | No | Minimum number of guests the venue should accommodate | |
| capacity_max | No | Maximum number of guests | |
| category | No | Venue category. Use 'conference-venues' for conferences, 'meeting-rooms' for meetings, 'workshop-spaces' for training/workshops, 'event-spaces' for receptions, 'private-dining-venues' for dinners, 'rooftop-venues' for rooftops with views, 'outdoor-venues' for gardens/terraces, 'unique-venues' for distinctive locations. | |
| event_type | No | Event type slug — e.g. 'team-building', 'conference', 'workshop', 'product-launch', 'gala-dinner', 'networking', 'training', 'corporate-retreat'. | |
| limit | No | Max number of results to return (default 10, max 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that data comes from Eventflare and returns real venue names, pricing, capacity, photos, and booking URLs. However, it does not mention whether the search is read-only, rate limits, or pagination behavior, leaving some uncertainty about side effects.
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 somewhat lengthy but well-structured: opens with core function, then lists search criteria, return value, and data source. Every sentence adds useful information, though some could be tightened. It is front-loaded with the main purpose.
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?
Given the absence of output schema and annotations, the description covers essential aspects: what the tool does, input parameters (extensive examples), and return data. It could mention pagination or ordering, but it adequately sets expectations for a search 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?
Schema coverage is 100%, so parameters are already well-documented. The description enriches understanding by providing concrete examples (e.g., city 'london', 'dubai') and mapping categories to event types (e.g., 'conference-venues' for conferences), adding value 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 clearly states it finds corporate event venues with specific criteria, including cities, capacity, category, and event type. It differentiates from sibling tools like get_venue_details (for specific venues) and list_cities (just city listings) by focusing on search functionality.
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 implies usage for venue search but does not explicitly state when to use this tool versus alternatives like get_venue_details or find_expert_advice. There is no 'when not to use' guidance, though the context is clear.
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. Dates show when Glama detected each change.
v2.0.0find_expert_adviceget_city_infoget_pricing_guideget_venue_detailslist_citiesrequest_quotesearch_venuesEach tool has a clearly distinct purpose: expert advice articles, city overview, pricing guide, venue details, city listing, quote request, and venue search. No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., find_expert_advice, get_venue_details, search_venues), making it easy to predict tool behavior from name.
Seven tools perfectly cover the domain of corporate event venue browsing and inquiry without unnecessary bloat or missing essential functions.
The tool set covers the full user workflow: discover cities, search venues, get pricing, view details, read expert advice, and request a quote. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Event venue CRM — manage inquiries, quotes, events and availability from any AI agent
AI-native corporate gifting & event infrastructure for Fortune 500. 70K products, 200+ brands.
Search nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
Ground your AI in verified Korean venue data: search & book across Seoul, Gyeonggi, Busan, Jeju.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mluckx/eventflare-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
