TavernFinder
Server Details
Find tabletop events, venues, and games. RSVP, register, create events via personal token.
- 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.9/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: event creation, user registration, RSVP, and separate searches for events, games, and venues. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., create_event, search_venues), making predictions easy.
With 6 tools covering core domain operations—search, create, register, RSVP—the count is well-scoped and not excessive.
The set covers essential lifecycle actions for events and users, but lacks update/delete for events or user profile management, leaving minor gaps.
Available Tools
6 toolscreate_eventAInspect
Create a new event (open event or private table) at a venue on behalf of the user. Requires a personal access token with the write:create_event scope. The user must be a member of the venue (player role at minimum); only staff/CL can create open events.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ISO date (YYYY-MM-DD) | |
| title | No | Event title (max 200 chars) | |
| endTime | Yes | HH:MM[:SS] end time | |
| tableId | No | Specific table UUID for table-based events | |
| venueId | Yes | UUID of the venue | |
| autoJoin | No | Whether the creator auto-joins (default true) | |
| gameBggId | No | BGG game ID, optional | |
| startTime | Yes | HH:MM[:SS] start time | |
| accessCode | No | Optional access code for private events | |
| description | No | Optional description (max 2000 chars) | |
| maxCapacity | No | Max participants |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral implications: acting on behalf of the user, requiring specific token scope, and role-based constraints. However, it does not mention side effects like notifications or immediate event creation, but the core behavioral traits are covered.
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, front-loading the purpose and immediately providing restrictive conditions. Every word is necessary; no fluff 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?
Despite having no output schema and no annotations, the description omits what the tool returns upon success (e.g., event ID or confirmation). It also lacks error scenarios or how to differentiate between open event and private table creation via parameters. The core is there, but gaps exist for a creation tool with many parameters.
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 11 parameters are documented in the input schema with descriptions (100% coverage). The tool description does not add any additional meaning or context about parameters beyond what the schema already provides, so it meets the baseline without adding 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?
The description clearly states the verb ('Create'), the resource ('event'), and the context ('at a venue on behalf of the user'). It distinguishes between open events and private tables, which differentiates it from siblings like rsvp_event 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?
The description explicitly specifies required authorization (personal access token with write:create_event scope) and membership requirements (user must be venue member, player role minimum). It also clarifies role-based restrictions: only staff/CL can create open events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_userAInspect
Create a new TavernFinder account. Returns access + refresh tokens that the agent can use immediately. The new user is unverified until they click the email verification link, but most read paths still work.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | First name | |
| Yes | Email address (will receive a verification mail) | ||
| locale | No | Preferred locale: 'pt' | 'en' | 'es' (default 'pt') | |
| lastName | Yes | Last name | |
| password | Yes | Password, minimum 8 characters | |
| tosAccepted | Yes | Must be true. Confirms the user agreed to https://tavernfinder.com/terms |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the new user is unverified until email click but most read paths work, and tokens can be used immediately. Does not cover rate limits or destructive actions, but these are less relevant for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of action and output. 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 6 parameters (5 required) and no output schema or annotations, the description covers the core functionality, return type, and a key behavioral caveat. Lacks return format details but is sufficient for most use cases.
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 adds minimal value beyond the schema. It does not enrich the parameter descriptions or add behavior context beyond the tool's main action.
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 creates a new TavernFinder account and returns tokens, with a specific verb and resource. It is distinct from sibling tools which deal with events, games, and venues.
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 when-to-use or alternatives are provided. The domain (user registration) is distinct from siblings, so usage is implied but not guided with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rsvp_eventAInspect
RSVP / join a TavernFinder event on behalf of the authenticated user. Requires a personal access token with the write:rsvp scope. Use search_events first to find the venueId + eventId pair.
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | UUID of the specific event to join | |
| venueId | Yes | UUID of the venue hosting the event | |
| accessCode | No | Access code, only needed if the event is access-code-protected |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auth requirement and prerequisite search, but does not explain side effects (e.g., idempotency, rate limits, success/failure 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 sentences, front-loaded with purpose, no redundant information. Highly concise.
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 3-param tool with no output schema and no annotations, description covers purpose, prerequisites, and usage tip. Could mention idempotency or response, but overall adequate.
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 description adds minimal value beyond schema. It reinforces that venueId and eventId are needed and accessCode is optional, aligning with schema descriptions.
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 'RSVP / join a TavernFinder event' with specific verb and resource, distinguishing from siblings like create_event and 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?
Explicitly mentions prerequisite: personal access token with write:rsvp scope, and advises using search_events first to find venueId+eventId. Lacks explicit when-not-to-use or alternatives.
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 upcoming tabletop gaming events (tournaments, leagues, casual play) near a location.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the user for proximity search | |
| lng | No | Longitude of the user for proximity search | |
| type | No | Type of activity to search for | |
| limit | No | Maximum number of results to return | |
| gameBggId | No | BoardGameGeek ID to filter for a specific game |
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 only states it is a search (read) operation, but provides no details on authentication needs, rate limits, pagination, or what happens if no results. Lack of behavioral disclosure beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It efficiently communicates the core purpose. Structure is optimal for quick understanding.
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 5 parameters and no output schema, the description is minimal. It does not explain return format, result ordering, or how 'near' is determined. For a search tool, additional context would be beneficial, but the description is functionally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters. The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the description does not enhance parameter understanding.
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 'Search' and the resource 'upcoming tabletop gaming events', with specific types listed and location condition. It effectively distinguishes from sibling search tools like search_games and search_venues by focusing on 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 implies when to use (searching for events near a location) but does not provide explicit when-not-to-use guidance or compare with alternative sibling tools such as search_games or search_venues. Usage context is implied but not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_gamesAInspect
Search for board games in our catalog to find their BoardGameGeek IDs (required for filtering events by game).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Name of the board game to search for | |
| limit | No | Maximum number of results to return |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations, so description bears full burden. Discloses search behavior and ID retrieval but omits details like result format, pagination, or rate limits. Adequate for a simple search 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?
Single sentence, 19 words, front-loaded with action and purpose. 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?
Given no output schema and simple parameters, description provides enough context for a search tool. Explains why the ID matters. Could mention response format but not critical.
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% for both parameters. Description adds context about the ID's purpose but does not enhance parameter understanding beyond schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches for board games to find BoardGameGeek IDs, a specific verb+resource+outcome. Distinguishes from sibling tools (events, users, venues) by specifying the domain.
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 explains why the output is needed (required for filtering events by game). Implies use before event-related tools, though does not state when not to use or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_venuesBInspect
Search for local game stores, hobby centers, and community spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query (venue name or game category) | |
| lat | No | Latitude for proximity sorting | |
| lng | No | Longitude for proximity sorting | |
| city | No | Filter by city name | |
| products | No | Comma-separated list of products sold (e.g., 'board_games,tcg_products,miniatures') | |
| amenities | No | Comma-separated list of amenities (e.g., 'play_space,food,game_library') | |
| unclaimed | No | Filter for venues that haven't been claimed by owners yet | |
| venueType | No | Type of venue |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'Search' without disclosing behavior like sorting, pagination, authentication needs, or result format. Minimal transparency beyond tool name.
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?
A single, front-loaded sentence with no wasted words; it is appropriately compact for a clear function.
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 8 optional parameters and no output schema, the description fails to explain how parameters interact, what results look like, or how to effectively use filters, leaving gaps for a complex 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 applies. Description does not elaborate on parameters beyond what schema already provides, meeting but not exceeding expectations.
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 'Search' and resource 'venues', specifying target types (game stores, hobby centers, community spaces), which distinguishes it from sibling tools like search_events or search_games.
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 when-to-use or when-not-to-use guidance, but the noun 'venues' implies usage for venue searches among siblings focused on events, games, etc.
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!