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.8/5 across 6 of 6 tools scored.
Each tool targets a distinct operation: venue search, game search, event search, event creation, user registration, and RSVP. There is no overlap in purpose, and descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern with underscores (create_event, register_user, rsvp_event, search_events, search_games, search_venues). No deviations or mixed conventions.
With 6 tools covering search, creation, registration, and RSVP for events and venues, the count is well-scoped. Each tool serves a clear purpose without redundancy or excessive granularity.
Missing critical operations: no login tool for existing users (only registration returns tokens), no update or delete for events, and no way to view a user's own events. These gaps will cause agent failures for common workflows.
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, description reveals auth and role requirements but omits side effects, idempotency, or return 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 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 11 params and no output schema, the description covers creation and constraints but does not specify return values or behavior for missing optional params.
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. Description adds minimal parameter meaning beyond schema, e.g., not explaining which parameters control event type.
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 action (create event), resource (event), and differentiates between open event and private table. It sufficiently distinguishes from sibling tools like register_user and rsvp_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?
Provides prerequisites (auth scope, membership role) and restrictions (only staff/CL can create open events). Lacks explicit mention of 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.
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?
With no annotations, the description carries full burden. It discloses that tokens are returned, the user is unverified until email confirmation, and read paths work. This provides useful behavioral context beyond the schema.
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, no redundant words. Front-loaded with key action and purpose. 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?
Covers creation, token return, verification status, and partial access. No output schema exists, so mentioning token return is helpful. Could add error scenarios or prerequisites (e.g., need unique email).
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 no additional parameter-specific meaning; it focuses on overall behavior.
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 'Create a new TavernFinder account' with specific verb and resource. It immediately distinguishes from sibling tools (events, games, venues) which are unrelated to user registration.
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 it should be used for new account creation. It does not explicitly state when not to use it (e.g., for login), but given sibling tool names, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Discloses authentication requirement (personal access token with 'write:rsvp' scope). Without annotations, the description carries the full burden, but it omits details like whether the operation is idempotent or what happens on duplicate RSVP. Reasonably transparent but not exhaustive.
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 main purpose, followed by essential usage hints. No fluff or 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?
Given no output schema and write nature, the description covers core usage and prerequisites. It could mention expected return values or error conditions, but overall sufficient for correct invocation.
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 no new parameter semantics beyond what the schema already provides (the accessCode explanation is redundant). 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?
The description clearly states the action 'RSVP / join an event' and identifies the target system 'TavernFinder'. It distinguishes from sibling tools like 'search_events' (search vs join) and 'create_event' (create vs join).
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 instructs to use 'search_events' first to obtain venueId and eventId, and mentions the required OAuth scope. However, it does not specify situations where using this tool would be inappropriate (e.g., already RSVPed).
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 must convey behavior. It states it searches for upcoming events near a location, which is a read operation. However, it does not disclose rate limits, authentication needs, or how results are ordered. The basic behavior is clear but lacks depth.
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 sentence of 12 words, front-loaded with the key action and resource. No fluff, every word 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?
Given no output schema, the description does not need to detail return values. However, it lacks information about result ordering, pagination, or filtering combinations. For a search tool with 5 parameters, it is minimally complete but could be more helpful.
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 minimal semantic value by contextualizing lat/lng with 'near a location' and giving examples of event types that align with the 'type' enum. It does not significantly extend the schema's meaning.
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', the resource 'upcoming tabletop gaming events', and the scope 'near a location', with examples of event types (tournaments, leagues, casual play). This effectively distinguishes it from siblings like 'create_event' 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?
The description implies that lat/lng are needed for proximity search but does not explicitly say when to use this tool versus alternatives like 'search_games' or 'search_venues'. No prerequisites or limitations are stated, making it adequate but not fully guiding.
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?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, any rate limits, or side effects. It adds context about the purpose (getting IDs) but lacks behavioral details expected for a search 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?
The description is a single sentence that efficiently conveys the tool's purpose and its relation to filtering events. No extraneous information, well-structured.
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 (two parameters, no output schema), the description adequately covers purpose and the key output (BoardGameGeek IDs). It could mention that results include the game name and ID, but the purpose is clear enough.
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 does not add new meaning beyond the schema; it only reinforces that the q parameter is for searching by game name. No additional parameter semantics are provided.
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 'board games', and specifies the purpose: to find BoardGameGeek IDs, which are needed for filtering events. This distinguishes it from sibling tools like search_events and search_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?
The description indicates when to use this tool: when you need game IDs to filter events. However, it does not explicitly mention when not to use it or provide alternatives, though no direct alternative exists among siblings.
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; description does not disclose behavioral traits such as return format, data source, rate limits, or side effects. Only states 'search', which is too vague.
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, front-loaded sentence that clearly states the tool's purpose with no unnecessary words. 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?
Despite many parameters (8) and no output schema, the description does not explain return behavior, sorting (lat/lng likely for proximity but not stated), or how results are organized. Insufficient for 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?
Input schema has 100% description coverage for all 8 parameters, so description adds no additional meaning beyond parameter names and schemas. 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?
Clear verb 'search' and resource 'venues', specifying types: game stores, hobby centers, community spaces. Distinct from sibling tools that focus on events or 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/when-not guidance or alternatives, but sibling tool names (search_events, search_games) imply domain boundaries. A minimal score of 3 as usage is somewhat implied.
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!