Eventflare MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
Seven tools perfectly cover the domain of corporate event venue browsing and inquiry without unnecessary bloat or missing essential functions.
Completeness5/5
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.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![eventflare-mcp-server MCP server](https://glama.ai/mcp/servers/mluckx/eventflare-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mluckx/eventflare-mcp-server)

Score Badge

Copy to your README.md:

[![eventflare-mcp-server MCP server](https://glama.ai/mcp/servers/mluckx/eventflare-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mluckx/eventflare-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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