LONG Events
Server Details
Search events, conference weeks, cities, venues and artist schedules via remote MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 13 of 13 tools scored.
Most tools have distinct purposes (cities, event details, schedule, now playing, venues, artists, organizers), but there is some overlap among the five event-week-related tools (get_event_weeks, get_event_week_details, get_event_week_cities, search_event_weeks, get_event_week_tags) that could cause confusion. Descriptions help differentiate them.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_cities, search_events, get_event_schedule), making it easy to predict tool names.
With 13 tools, the surface is well-scoped for an event discovery server. It covers core operations without being overwhelming or too sparse.
The tool set covers most read operations needed for event discovery (cities, venues, events, schedules, artists, organizers). Missing are venue detail lookups and artist profile searches beyond set times, but these are minor gaps for the apparent domain.
Available Tools
13 toolsget_citiesAInspect
List cities that have events, with statistics like total events and recent activity. Use this to help users discover active event scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of cities to return | |
| country | No | Filter by country name | |
| min_events | No | Minimum number of total events |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It hints at output contents ('statistics like total events and recent activity') but does not disclose behavioral details such as read-only nature, error handling, rate limits, or ordering. Some transparency but significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No unnecessary words; 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?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides a high-level purpose but lacks details on what 'statistics' specifically include, how parameters affect output, or ordering. Adequate but not fully complete for an agent to use optimally.
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 parameter descriptions already provided. The tool description adds no additional meaning to the parameters (limit, country, min_events), so it does not improve upon 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?
Description clearly states the tool lists cities with events and includes statistics like total events and recent activity. It distinguishes from sibling tools by focusing on cities rather than specific events or venues, though it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides a use case ('help users discover active event scenes') but does not specify when to use this tool over alternatives like search_events or get_venues. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_detailsAInspect
Get full details for a specific event by its ID. Returns complete information including description, venue details, and ticket URL.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | The UUID of the event to retrieve |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns specific fields (description, venue details, ticket URL) but does not mention safety, auth needs, rate limits, or side effects. Adequate for a simple read operation.
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 concise sentences front-load the core purpose and immediately state what is returned. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one required parameter and no output schema, the description lists return fields, which compensates for missing schema. It is mostly complete but could mention if authentication is required or behavior on missing IDs.
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 one parameter with a descriptive name and description. Schema description coverage is 100%, so the description adds no extra semantic value beyond the schema. Baseline score 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 clearly states the tool's purpose: to get full details for a specific event by its ID, listing included information. It distinguishes from sibling tools like search_events by focusing on single event retrieval with complete details.
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 when an event ID is known, but does not explicitly contrast with sibling tools like search_events or get_event_schedule. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_scheduleAInspect
Get the DJ/artist schedule for a festival or party event. Returns set times, stages, and artists. Use this to answer questions like 'What time does ANOTR play?' or 'What's happening at AYA on New Year's Eve?'
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Filter by stage name | |
| artist | No | Search for specific artist in the schedule | |
| event_id | No | UUID of the event to get schedule for | |
| event_name | No | Name of the event to search for (if event_id not known) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool returns, but does not mention any side effects, authentication needs, rate limits, performance expectations, or error handling (e.g., if event not found). For a read operation, basic transparency is lacking.
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 two sentences long, with the first sentence stating the core purpose and the second providing example usage. It is front-loaded, efficient, and contains no filler, making it easy for an AI agent to parse quickly.
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 the basic return types (set times, stages, artists) and parameter filters. However, it does not clarify that all parameters are optional, how event identification works (event_id vs event_name), or the structure of the response. It is adequate but not fully comprehensive.
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 four parameters have descriptions in the input schema (100% coverage). The description text adds minimal value beyond the schema; it does not clarify the trade-off between 'event_id' and 'event_name' or provide additional usage context. Baseline 3 is appropriate since schema already covers parameter details.
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: 'Get the DJ/artist schedule for a festival or party event. Returns set times, stages, and artists.' It uses a specific verb ('Get') and resource ('schedule'), and distinguishes from siblings like 'get_event_details' and 'search_events' by focusing on schedule retrieval. Including example questions further clarifies the intended use.
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 includes example questions ('What time does ANOTR play?', 'What's happening at AYA on New Year's Eve?'), which imply when to use this tool. However, it does not explicitly state when not to use it or provide alternatives among siblings, leaving some ambiguity for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_week_citiesAInspect
List cities that have upcoming event weeks with their counts. Use this to discover where major conferences are happening.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes basic behavior but does not disclose ordering, pagination, definition of 'upcoming', or whether data is real-time.
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 action and purpose, no wasted words.
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?
Tool is simple with no parameters, but lacks output schema or description of return format (e.g., list of city names with count values). Could be more complete for agent usage without output schema.
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?
No parameters, so schema coverage is 100%. Description does not need to add param info; baseline of 4 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?
Clearly states it lists cities with upcoming event weeks and their counts. Distinguishes from sibling 'get_cities' by focusing on cities with events, but could be more explicit about what 'counts' refers to.
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?
Suggests use case ('discover where major conferences are happening') but does not provide when-to-use vs alternatives like 'get_cities' or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_week_detailsAInspect
Get full details for a conference week including all its side events. Use this to help users see everything happening during a major conference.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | The slug of the event week (alternative to week_id) | |
| week_id | No | The UUID of the event week to retrieve | |
| event_week_id | No | Alias for week_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It states the tool returns 'full details' and 'side events,' but does not disclose any behavioral traits such as rate limits, authentication needs, or whether it is idempotent. The lack of detail on what constitutes 'full details' leaves the agent guessing about the response structure.
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 consists of two sentences that efficiently convey purpose and usage guidance. Every sentence adds value with no unnecessary words or repetition.
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?
The tool has 3 parameters (all optional, 100% schema coverage) and no output schema. The description explains it returns 'full details and side events' but does not specify the exact fields returned (e.g., dates, venues, organizers). For a detail-retrieval tool, more information about the output structure would improve completeness.
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%, meaning all three parameters (slug, week_id, event_week_id) are described in the input schema. The description does not add any extra meaning beyond what the schema provides, e.g., which parameter to prefer or any constraints. Baseline score of 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?
Description clearly states 'Get full details for a conference week including all its side events.' This provides a specific verb and resource, and the inclusion of side events distinguishes it from tools like get_event_weeks (which lists weeks) and get_event_details (single event).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence, 'Use this to help users see everything happening during a major conference,' gives context for when to use the tool. It does not explicitly state when not to use or mention alternatives, but the sibling tool names imply alternatives for listing weeks or single events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_weeksAInspect
List upcoming conference weeks, festivals, and multi-day event series (like ETH Denver, Devconnect, Token2049). Use this to help users plan trips around major conferences.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag (e.g., 'crypto', 'music', 'tech') | |
| city | No | Filter by city name | |
| limit | No | Maximum number of event weeks to return | |
| country | No | Filter by country name | |
| include_past | No | Include past event weeks (default false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it lists 'upcoming' events, implying a time filter, but does not explain default behavior (e.g., include_past param) or response format. No annotations are provided, so the description bears the burden but gives only basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. The purpose and a sample use case are presented clearly and front-loaded.
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 5 parameters and no output schema, the description could explain return structure or defaults. However, the tool seems intended for listing summaries, and companion tools (get_event_week_details) exist for details. It adequately covers the core use case.
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 the description does not need to add parameter details. The description does not mention any parameters, which is acceptable given full schema documentation.
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 lists upcoming conference weeks, festivals, and multi-day event series, with specific examples (ETH Denver, Devconnect, Token2049). It distinguishes from siblings like search_event_weeks by using 'list' rather than 'search'.
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 a usage hint: 'Use this to help users plan trips around major conferences.' However, it does not specify when not to use it or contrast with alternatives like search_event_weeks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_week_tagsAInspect
List all tags used in event weeks with their counts. Use this to discover types of conferences available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden. It describes a read operation with no side effects, but doesn't discuss authentication, rate limits, or empty results. Acceptable for a simple 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 concise sentences, front-loaded with action. Zero waste, every word 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?
Adequate for a simple listing tool with no parameters. Lacks explicit return format, but context is mostly complete given no output schema.
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?
Zero parameters, baseline 4. Description adds value beyond empty schema by specifying 'all tags' and 'counts', clarifying what the tool returns.
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?
Description clearly states the verb 'List' and resource 'tags used in event weeks' with specific details (counts). It differentiates from sibling tools like get_cities and get_event_details by focusing on tags.
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?
Provides context 'discover types of conferences available', implying usage for overview. Does not explicitly exclude alternatives, but given sibling tools cover specific entities, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_now_playingAInspect
Get what's currently playing at festival/party events. Returns live stage information with current artists. Use this to answer 'What's on now?' or 'Who's playing right now at AYA?'
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter by city | |
| event_id | No | Filter to specific event | |
| event_week_id | No | Filter to specific event week/festival |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions returns live stage information but does not clarify how 'current' is determined (e.g., real-time vs schedule-based) or any 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?
Two concise sentences front-loading the core purpose and ending with example use cases. No wasted words.
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 and no output schema, the description sufficiently explains return value (stage info, current artists). Sibling tools are listed for context.
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. Description does not add additional semantics beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it gets what's currently playing at festival/party events with live stage info and current artists. Clearly differentiates from sibling tools like get_event_schedule.
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 provides use cases: answering 'What's on now?' or 'Who's playing right now at AYA?'. Does not exclude any scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_venuesBInspect
List venues in a city with their event history. Use this to help users find popular venues or discover new spots.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name to search venues in | |
| limit | No | Maximum number of venues to return |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action (listing) without disclosing any behavioral traits such as side effects, authentication needs, rate limits, or read-only nature. The description carries the full burden but adds minimal transparency.
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 two sentences with no wasted words: one for function, one for usage. It is appropriately front-loaded. Could be slightly more explicit about 'event history' but overall 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?
For a simple tool with 2 parameters and no output schema, the description covers the basic purpose and use case. However, it lacks details on return format (e.g., what fields, pagination) and does not mention siblings for disambiguation, leaving some context gaps.
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%, meaning the schema already documents both parameters (city, limit). The description does not add new meaning beyond naming 'city' in the first sentence. Baseline of 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 ('List') and resource ('venues in a city'), and distinguishes from sibling tools that focus on cities or events. The phrase 'with their event history' adds context, though slightly vague.
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 a general use case ('find popular venues or discover new spots') but does not explicitly guide when to use this tool versus alternatives like get_event_details or search_venues. No exclusions or competing tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_artistsAInspect
Search for artist set times across all events. Use this to find when and where a specific artist is playing. Great for answering 'When does Bonobo play?' or 'Where can I see Tale of Us?'
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter by city | |
| end_date | No | End date filter (YYYY-MM-DD) | |
| start_date | No | Start date filter (YYYY-MM-DD) | |
| artist_name | Yes | Artist name to search for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it searches 'across all events' but does not clarify default date range, case sensitivity, partial matching, or output format. Lacks detail on behavior without filters.
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?
Extremely concise: two sentences plus a sentence with examples. Front-loaded with action. Every sentence adds value with no 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?
No output schema, so description should explain return values. It does not describe what the search result looks like (e.g., list of events with times). Does not address pagination or result limits. Adequate but incomplete.
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 baseline is 3. Description adds no parameter-level detail beyond schema; example queries do not enhance parameter understanding. No extra value.
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?
Description clearly states verb 'Search for' and resource 'artist set times across all events'. Distinguishes itself from siblings like search_events and get_event_schedule by focusing on artist-specific queries. Examples reinforce purpose.
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?
Provides clear use cases with example questions ('When does Bonobo play?') and states 'Use this to find when and where a specific artist is playing.' Does not explicitly exclude alternatives or state when not to use, but guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsAInspect
Search for events near a location with optional filters. Returns events with name, venue, date, category, and ticket URL. Use this to help users find events in a city or near coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name like 'Berlin', 'New York', 'London' | |
| limit | No | Maximum number of events to return (default 20, max 100) | |
| country | No | Country name to filter by | |
| category | No | Event category like 'electronic', 'rock', 'tech', 'crypto' | |
| end_date | No | End date filter in ISO format (YYYY-MM-DD) | |
| latitude | No | Latitude for location-based search | |
| longitude | No | Longitude for location-based search | |
| radius_km | No | Search radius in kilometers (default 50) | |
| start_date | No | Start date filter in ISO format (YYYY-MM-DD) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool returns events with specific fields but does not disclose any behavioral traits like read-only nature, auth requirements, rate limits, or what happens with no parameters. It implies a fetch operation but lacks full transparency.
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, then return information and usage advice. Every sentence adds value with no wasted words.
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 9 optional parameters and no output schema or annotations, the description gives a general overview but lacks details on how parameters interact (e.g., city vs coordinates), typical usage patterns, or default behavior when no parameters are provided. Adequate but not thorough.
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 baseline is 3. The description adds a brief usage context ('with optional filters') but does not provide additional semantic detail beyond what the schema already provides for each parameter.
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 'searches for events near a location with optional filters', specifying the verb ('search'), resource ('events'), and context. It mentions return fields (name, venue, date, category, ticket URL), distinguishing it from sibling tools like get_event_details or search_artists.
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 this to help users find events in a city or near coordinates', giving clear usage context. It does not explicitly state when not to use or alternatives, but the sibling tools list implies other tools for specific cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_event_weeksBInspect
Search event weeks by name, description, or city. Use this to find specific conferences or festivals.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Search query to match against name, description, or city |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral traits. It only states the search capability, omitting details like read-only nature, pagination (limit parameter implied but not explained), or error handling. No contradictory statements.
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 at two sentences, front-loading the core action. It wastes no words, though it could be slightly more structured with explicit parameter references.
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 params, no output schema), the description is adequate for basic usage. However, it does not cover return format or selection criteria among siblings, which a more complete description would address.
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 descriptions for both query and limit. The description adds value by confirming that query matches name, description, or city, but does not add new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches event weeks by name, description, or city, which is a specific verb-resource combination. It also mentions 'conferences or festivals' as examples, but does not explicitly differentiate from sibling tools like get_event_weeks.
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 suggests using the tool to find specific conferences or festivals, providing context. However, it lacks explicit when-not-to-use instructions or mention of alternative tools like get_event_weeks for listing all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_organizersBInspect
Search organizer profiles enriched from event data. Returns organizer names, source, website/contact details, Instagram profile URL plus handle, and scrape status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of organizers to return (default 20, max 100) | |
| query | No | Search by organizer name, website, email, or Instagram handle | |
| source | No | Filter by event source (e.g., facebook, eventbrite, lu.ma) | |
| missing_contacts_only | No | Only return organizers missing website, email, phone, or Instagram (default false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral detail by listing return fields, but it does not explicitly state side effects (e.g., read-only, no modifications) or authentication 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?
Single sentence is concise and front-loaded with purpose. Could be slightly improved by noting the default limit, but that is captured in the schema.
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, the description lists return fields adequately. However, it lacks guidance on ordering, pagination, or when to apply filters, which would help complete the picture for the agent.
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 the schema already documents all parameters. The description adds context about return fields but not additional parameter meaning 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 searches organizer profiles with enriched event data and lists the specific return fields (names, source, website, etc.), distinguishing it from sibling tools like search_artists or search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., search_artists, search_events). Usage context is only implied by the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!