catchaset
Server Details
Live-music shows in Austin & Chicago matched to your taste (pass artists you like).
- 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 4.5/5 across 3 of 3 tools scored.
Each tool serves a distinct purpose: find_events for general event search, find_live_shows for artist-specific matching, and overview for system health. No overlap in functionality.
Two tools follow verb_noun pattern (find_events, find_live_shows) while one uses a single noun (overview). Mostly consistent with a minor deviation.
Three tools cover the essential operations for a music event discovery service: search, personalized matching, and health monitoring. Neither too few nor too many.
Covers general search, artist-driven discovery, and system status. Missing explicit genre or city listing tools, but the domain is well-scoped for consumer usage.
Available Tools
3 toolsfind_eventsAInspect
Find upcoming live-music events in a supported city (Austin or Chicago), filtered by free-text query, date range, and/or genre. Returns taste-neutral event records with source attribution, ticket links, and a freshness timestamp — the same public data catchaset.live shows signed-out visitors. Does NOT rank by personal taste. Results are capped per call; page with the returned next_cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to search. Only Austin and Chicago are supported; any other value returns an unsupported_city note and defaults to Austin. | Austin |
| genre | No | Optional genre substring filter. | |
| limit | No | Max events to return (1-100). | |
| query | No | Optional free-text filter matched (case-insensitive substring) against headliner, artists, venue, and genre. | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| date_to | No | Optional inclusive upper bound, ISO date YYYY-MM-DD. | |
| date_from | No | Optional inclusive lower bound, ISO date YYYY-MM-DD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully addresses behavioral traits: it declares read-only semantics (public data, no personalization), return contents (source attribution, tickets, timestamp), and error behavior (unsupported city falls back to Austin). It also mentions pagination limits.
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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value: scope, filtering, return contents, and behavioral notes. No redundant text.
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 7 optional parameters and no output schema, the description sufficiently explains what the tool returns (event records with source attribution, ticket links, freshness timestamp) and how to paginate. Error handling for unsupported cities is also covered.
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 baseline is 3. The description groups parameters (free-text, date range, genre) but does not add much beyond the schema's own descriptions. It explains the cursor's origin from next_cursor, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds upcoming live-music events in supported cities (Austin or Chicago) with filtering options. It specifies the action (find) and the resource (events), and implicitly differentiates from siblings by emphasizing taste-neutrality and public data.
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 on when to use this tool (for taste-neutral event discovery) and what it does not do (does not rank by personal taste). It also explains pagination with next_cursor. However, it does not explicitly contrast with sibling tools like find_live_shows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_live_showsAInspect
Given a list of artists the user likes, find upcoming shows in a supported city (Austin or Chicago) where one of those artists is on the bill, ranked (most matches first, then soonest). Taste is a PARAMETER — no account or login needed. Each result includes why_matched (which of the user's artists plays). This is direct-artist matching; genre-based discovery of similar artists is available in the CatchaSet web app, not here.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to search. Only Austin and Chicago are supported; other values default to Austin with an unsupported_city note. | Austin |
| limit | No | Max shows to return (1-100). | |
| cursor | No | Opaque pagination cursor from a previous response's next_cursor. | |
| artists | Yes | Names of acts the user likes. Required — this is the taste to match. | |
| date_to | No | Optional inclusive upper bound, ISO date YYYY-MM-DD. | |
| date_from | No | Optional inclusive lower bound, ISO date YYYY-MM-DD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers ranking logic, match details (why_matched), authentication requirements (none), city limitations, and pagination. It fully discloses the tool's 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?
The description is a compact single paragraph with front-loaded purpose. Every sentence adds value, and there is no redundancy or unnecessary detail.
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 covers key aspects: input, city support, ranking, result field (why_matched), pagination, and authentication. Lacks explicit mention of output format but is largely complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minor context (e.g., 'taste is a parameter' reiterates artists parameter, city note) but does not significantly augment 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 the tool finds upcoming shows in specific cities based on a list of artists, with ranking logic. It explicitly distinguishes itself from genre-based discovery available elsewhere, differentiating from sibling tools.
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 context: input is a list of artists, supported cities only. Explicitly describes when not to use (genre-based discovery goes to web app). Does not directly compare to sibling tools but implies a distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
overviewAInspect
Operational state of the CatchaSet event feed: per-city event counts, data sources, last-refresh time, staleness, and coverage. No input. Call this to check health/coverage before relying on find_events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It describes the output (counts, sources, refresh time, staleness, coverage) and implies no side effects. It does not mention permissions or error cases, but for a read-only status check, this is sufficient.
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. The first sentence front-loads the purpose and output details, and the second gives usage guidance.
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 enumerates the expected return values (counts, sources, refresh time, staleness, coverage). It also references a sibling tool and provides a clear use case, making it complete for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds no parameter-specific meaning. Baseline for zero parameters is 4. The description does not need to provide additional parameter info.
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 that the tool returns the operational state of the CatchaSet event feed, listing specific data points like per-city event counts, data sources, and staleness. It distinguishes itself from sibling tools (find_events, find_live_shows) by focusing on health and coverage.
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?
Explicit guidance is provided: 'Call this to check health/coverage before relying on find_events.' This tells the agent exactly when to use it and hints at a precondition for using a sibling tool.
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!