Find Salsa and Bachata events and destination guides worldwide. Four public, read-only tools resolve locations, search upcoming events, retrieve event details and get existing guide summaries. Includes a rolling year of scheduled dates, published translations and canonical Salsa Vida links. No authentication required. Recurring dates reflect recorded schedules, not organizer confirmation. Documentation: https://www.salsavida.com/developers/mcp/
Read public event facts and dated occurrences within a requested window (default UTC today through 13 days later; pass user-local dates for today/tonight). Unknown timezones remain null. Inactive/private events are unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | ||
| event_id | Yes | ||
| language | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
| price | Yes | |
| title | Yes | |
| venue | Yes | |
| dances | Yes | |
| source | Yes | |
| address | Yes | |
| date_to | Yes | |
| summary | Yes | |
| coverage | Yes | |
| end_time | Yes | |
| event_id | Yes | |
| timezone | Yes | |
| date_from | Yes | |
| freshness | Yes | |
| time_mode | Yes | |
| visit_url | Yes | |
| start_time | Yes | |
| event_types | Yes | |
| occurrences | Yes | |
| salsa_styles | Yes | |
| canonical_url | Yes | |
| calendar_basis | Yes | |
| dates_are_local | Yes | |
| locale_fallback | Yes | |
| date_verification | Yes | |
| freshness_warning | Yes | |
| returned_language | Yes | |
| source_checked_at | Yes | |
| changes_checked_at | Yes | |
| source_modified_at | Yes | |
| default_window_basis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond this: only public events are accessible, inactive/private events are unavailable, unknown timezones remain null, and the default date window is precisely defined. No contradiction exists between the description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the primary purpose, and every sentence contributes behavioral or usage value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value documentation is unnecessary. The description covers public-only access, date window defaults, timezone behavior, and availability constraints. It is slightly incomplete on exact date formats, but the schema and required event_id field fill most of the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for date-related parameters by explaining the default window and user-local date expectation, but it does not describe event_id or language semantics. This is partial compensation rather than full parameter 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 names a specific verb ('Read'), a clear resource ('public event facts and dated occurrences'), and a window constraint. It does not explicitly distinguish itself from siblings like search_events, but the resource is specific enough that an agent can infer the difference between reading a single event's facts and searching for 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?
The description provides clear context for when to use the tool by explaining the default UTC window and instructing the caller to pass user-local dates for today/tonight. It does not state exclusions or name alternatives, but the usage context is actionable and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public Salsa Vida city, region or country guide summary and its canonical link. Uses only existing published language versions, with English fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| location | Yes | Salsa Vida source location ID, slug, or location name. Use search_locations to disambiguate. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| source | Yes | |
| summary | Yes | |
| coverage | Yes | |
| freshness | Yes | |
| visit_url | Yes | |
| location_id | Yes | |
| canonical_url | Yes | |
| calendar_basis | Yes | |
| dates_are_local | Yes | |
| locale_fallback | Yes | |
| freshness_warning | Yes | |
| returned_language | Yes | |
| source_checked_at | Yes | |
| changes_checked_at | Yes | |
| default_window_basis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: only public guides are accessible, only existing published language versions are used, and there is an English fallback. It does not disclose every edge case, but the additions are meaningful and non-contradictory.
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 filler. The primary action and resource are front-loaded in the first sentence, and the second sentence adds essential language behavior without 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?
For a simple, read-only, idempotent tool with an output schema and safe annotations, the description covers the essential decision factors: what it reads, the public scope, supported guide levels, and language fallback. The parameter schema and output schema cover the remaining invocation details.
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 description adds meaning not fully present in the schema: it restricts locations to city, region, or country guides and explains that the language parameter falls back to English when a requested published version is unavailable. This supplements the 50% schema coverage, although the individual parameter descriptions already document location formats and the language enum.
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 uses a specific verb ('Read') and names a precise resource: a public Salsa Vida city, region, or country guide summary plus its canonical link. The guide scope inherently distinguishes it from sibling event and location-search tools, even without an explicit comparison.
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 gives clear context: use this when you want to read a public guide summary rather than search for locations or events. It does not explicitly list exclusions or name alternative siblings, but the schema's location description complements this by pointing to search_locations for disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find published salsa/bachata events for a location and dates. Defaults to UTC today through 13 days later; for today/tonight pass the user-local date. Supports up to one year, 50 results/page and 10 pages. response_size_limited means the page was shortened to fit; follow next_cursor. Narrow filters when pagination_limit_reached is true.
| Name | Required | Description | Default |
|---|---|---|---|
| dance | No | ||
| limit | No | ||
| cursor | No | ||
| date_to | No | ||
| language | No | ||
| location | Yes | Salsa Vida source location ID, slug, or location name. Use search_locations to disambiguate. | |
| date_from | No | ||
| event_type | No | ||
| salsa_style | No | Filter recorded Salsa style tags. Many events have no recorded style, so an empty result does not prove the style is absent. linear-salsa includes salsa-on1/salsa-on2; cuban-salsa includes salsa-rueda. |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| date_to | Yes | |
| results | Yes | |
| coverage | Yes | |
| location | Yes | |
| date_from | Yes | |
| freshness | Yes | |
| next_cursor | Yes | |
| calendar_basis | Yes | |
| dates_are_local | Yes | |
| freshness_warning | Yes | |
| source_checked_at | Yes | |
| changes_checked_at | Yes | |
| default_window_basis | Yes | |
| response_size_limited | Yes | |
| pagination_limit_reached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the read-only/idempotent annotations: default date behavior, UTC vs local date handling, one-year max range, 50-result pages and 10-page cap, and the meaning of response_size_limited with next_cursor. It also warns about pagination_limit_reached and suggests a corrective action. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver the core purpose, default behavior, edge cases, and pagination guidance with no filler. The most important operational detail (date defaults) is front-loaded, and each sentence earns its place.
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 search tool with an output schema present, the description covers the essential call semantics: defaults, pagination flags, and filter strategy. It leaves some parameter-level details undocumented, but the core invocation and common failure modes are well addressed. A little more detail on date format would make it fully complete.
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 only 22%, so the description must compensate. It does clarify date range defaults, page size, cursor semantics, and filter narrowing, but it does not explain date formats, event_type, dance, language, or cursor value mechanics. The added value is meaningful but incomplete for several parameters.
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 ('Find'), resource ('published salsa/bachata events'), and scope ('for a location and dates'). It clearly distinguishes itself from siblings like get_event (single event) and search_locations (location lookup), so an agent can identify this as the list/search tool.
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 gives practical usage context: default UTC date range, guidance to pass the user-local date for today/tonight, maximum one-year range, and a directional hint to narrow filters when pagination_limit_reached is true. It does not explicitly name alternatives or state when not to use the tool, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Salsa Vida cities, regions and countries by name, ignoring case and diacritics. Use the returned source location ID to resolve ambiguous names. Localized guides fall back to English where available. response_size_limited means the page was shortened to fit; follow next_cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| results | Yes | |
| coverage | Yes | |
| freshness | Yes | |
| next_cursor | Yes | |
| calendar_basis | Yes | |
| dates_are_local | Yes | |
| freshness_warning | Yes | |
| source_checked_at | Yes | |
| changes_checked_at | Yes | |
| default_window_basis | Yes | |
| response_size_limited | Yes | |
| pagination_limit_reached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behaviors: case- and diacritic-insensitive matching, English fallback for localized guides, and the meaning of response_size_limited with a concrete follow-up action. This adds real value and contains no contradictions.
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?
Four tightly packed sentences, each adding distinct information: core purpose, ambiguity resolution, localization behavior, and pagination semantics. No filler or repetition, and the most important purpose is 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?
The description covers the core search behavior, result ambiguity, localization fallback, and pagination signal. Combined with a rich output schema and readOnly/idempotent annotations, an agent has sufficient information to invoke the tool correctly.
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 0%, so the description carries the burden of explaining parameters. It clarifies query semantics ('by name') and cursor behavior ('follow next_cursor'), but limit and language are only indirectly addressed. This is partial compensation, not full.
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 uses a precise verb ('Find') with a specific resource ('Salsa Vida cities, regions and countries') and clear search behavior (by name, ignoring case and diacritics). This clearly distinguishes it from sibling tools like search_events and get_event, which target different resource types.
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 gives actionable guidance: use the returned source location ID to resolve ambiguous names, and follow next_cursor for truncated results. It does not explicitly contrast with sibling tools, but the context for when to search locations is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct operation: searching vs retrieving events, and searching locations vs retrieving guides. There is no overlap in purpose or ambiguity about when to use which.
All tool names follow a clean verb_noun pattern: get_event, get_guide, search_events, search_locations. The get/search distinction is intuitive and consistently applied.
Four tools is well-scoped for a read-only public events and guides server. Each tool addresses a necessary part of the user journey without bloat or redundancy.
The tool surface covers the full read-only workflow: find a location, search events, get event details, and read a guide. No missing operations are evident for the stated public-info domain.