TavernFinder

Server Details

Find tabletop events, venues, and games. RSVP, register, create events via personal token.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-21 20:00
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-20 03:25 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: registering users, searching for venues/games/events, creating events, and RSVPing to events. Even the two event-related actions (create_event vs rsvp_event) are unambiguous because one creates while the other joins.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_event, register_user, rsvp_event, search_events, search_games, search_venues. The naming is predictable and easy to navigate.

Tool Count5/5

With 6 tools, the server is well-scoped for a focused domain: discover venues/games/events, register a user, create an event, and RSVP. Each tool earns its place without redundancy or bloat.

Completeness4/5

The core workflow of searching, registering, creating, and joining events is covered. Minor gaps exist such as no update/cancel event or list user bookings, but they are workable and the primary use cases are solid.

Available Tools

6 tools

create_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.

ParametersJSON Schema

Name	Required	Description
`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

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the required OAuth scope, membership prerequisite, and role-based restrictions, which go beyond the simple action of creating. It does not detail side effects or error conditions, but the disclosed constraints are substantial and beyond schema information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences and front-loads the primary purpose. Every clause adds value: action, event type, venue, auth scope, membership requirement, and role limitation. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, multiple types of events, role restrictions) and the absence of both annotations and an output schema, the description covers the critical contextual prerequisites and constraints well. It lacks explicit return-value information, but that is not a strict requirement when no output schema exists. Overall, it is sufficiently complete for safe selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 11 parameters with descriptions (100% coverage), so the baseline is 3. The description adds semantic context by distinguishing 'open event' vs 'private table', which clarifies the roles of parameters like tableId and accessCode. This extra meaning elevates the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 create a new event (open or private table) at a venue. It uses a specific verb ('Create') and resource ('event'), and distinguishes itself from sibling tools like rsvp_event (attend) and search_events (read).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when the tool can be used: it requires a personal access token with `write:create_event` scope, the user must be a venue member, and only staff/CL can create open events. This implicitly instructs when not to use it (e.g., non-members), though it doesn't explicitly name alternative tools.

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 Tavern Finder account for the person you are helping, and get a reusable access token for it. Use the account immediately — booking and creating events work right away. STORE THE ACCESS TOKEN and reuse it for this person every time; do not call this again for someone you already registered. You also get a claim link: give it to the person so they can take ownership, set their own email and password, and see their bookings on the website. Only pass an email if the person actually gave you one — otherwise leave it out and they will set it when they claim.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	First name
`email`	No	Optional. The person's real email, only if they gave you one. Omit it rather than inventing one — they set it when claiming.
`locale`	No	Preferred locale: 'pt' \| 'en' \| 'es' (default 'pt')
`lastName`	Yes	Last name
`password`	Yes	Password, minimum 8 characters. Generate a strong random one; the person replaces it when they claim.
`tosAccepted`	Yes	Must be true. Confirms the user agreed to https://tavernfinder.com/terms

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and succeeds: it reveals side effects (account creation, token and claim link issued), immediate availability, non-repeatability, and the email-passing safety rule. This is rich 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Each sentence adds necessary operational information, with the core action front-loaded. Despite its length, it avoids filler and uses emphasis to highlight the token-storage requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description names the two return artifacts (access token and claim link) and explains how both should be used. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining when to pass or omit email and that the password should be a generated temporary value replaced at claim time.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Create a Tavern Finder account... and get a reusable access token.' This clearly differentiates the tool from event-centric 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit operational guidance: use the account immediately, store and reuse the token, and 'do not call this again for someone you already registered.' It also instructs when to omit email, making the expected invocation context unambiguous.

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 Tavern Finder 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.

ParametersJSON Schema

Name	Required	Description
`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

TDQS

A4/5.0

Behavior3/5

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 discloses the required auth scope ('write:rsvp'), which is valuable, and implies a write operation via 'RSVP / join.' However, it does not describe side effects (e.g., idempotency, confirmation response, or error conditions), which leaves some behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no filler. The primary action and auth requirement are front-loaded, followed by the essential usage hint. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides the essential prerequisite (search first) and auth requirement. For a simple RSVP action with no output schema, it is reasonably complete. It omits details about response format or idempotency, but those are minor for this tool type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond repeating that venueId and eventId form a pair; it doesn't provide extra context about parameter formats or relationships that the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('RSVP / join') and a specific resource ('a Tavern Finder event'), and clarifies it acts on behalf of the authenticated user. This clearly distinguishes it from siblings like create_event (creation) and search_events (discovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to 'Use search_events first to find the venueId + eventId pair,' which is a direct prerequisite. It also notes that accessCode is conditional, though it doesn't explicitly say when not to use this tool (e.g., for creating events), but the context makes that clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_eventsBInspect

Search for upcoming tabletop gaming events (tournaments, leagues, casual play) near a location.

ParametersJSON Schema

Name	Required	Description
`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

TDQS

B3.2/5.0

Behavior2/5

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 the search purpose and that events are 'upcoming' and 'near a location,' failing to disclose optional parameters, default limits, pagination, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence (14 words) that front-loads the primary action and resource. It is concise with no redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description is too sparse. It does not explain what the search results will contain, how missing coordinates affect the search, or how it relates to sibling tools like search_games or search_venues.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all five parameters, so the baseline is 3. The description adds a high-level domain context but no parameter-specific enhancement beyond the schema. Mentions of 'tournaments, leagues, casual play' are not directly tied to the enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (search) and resource (upcoming tabletop gaming events), and 'near a location' adds geographic context. It distinguishes the tool from siblings like search_games and search_venues by the resource type, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for location-based event search, but does not provide explicit when-to-use guidance or exclusion criteria. Sibling tools exist, but no comparison or alternative recommendations are given.

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).

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	Name of the board game to search for
`limit`	No	Maximum number of results to return

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. The verb 'Search' implies a non-mutating read operation, which is the primary behavior. However, the description does not explicitly state that it is read-only or safe, nor does it mention any output format beyond the implicit BGG ID.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the action ('Search') and the resource. No unnecessary words are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (2 parameters, no output schema, no annotations), the description is adequate. It states the tool's purpose and the reason for using it (to get BGG IDs for filtering events). The schema covers parameter semantics, so the description doesn't need to repeat them. However, it could be slightly more explicit about the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters (q and limit), so the baseline is 3. The description adds the context that q is the game name used to find BGG IDs, but it does not provide additional details about the limit parameter or any constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Search' with the resource 'board games in our catalog' and states the purpose: to find BoardGameGeek IDs. This clearly distinguishes the tool from sibling search 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions that the tool is 'required for filtering events by game', which clarifies the primary use case. However, it does not explicitly mention alternatives or exclusions, though the purpose makes it self-evident.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_venuesCInspect

Search for local game stores, hobby centers, and community spaces.

ParametersJSON Schema

Name	Required	Description
`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

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure, yet it only restates the search action and target resources. It does not describe result format, sorting behavior, pagination, permissions, or any side effects, providing no behavioral context beyond the tool's name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words and leads with the action verb. It is appropriately front-loaded and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter search tool with no output schema, the one-line description is insufficient. It does not describe how results are ordered, whether filters are combinable, or what the response contains, making it incomplete for effective agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter already has explicit documentation. The description adds no parameter details or filter combination semantics, so it provides no added value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Search' and names the resource types (game stores, hobby centers, community spaces), which distinguishes it from sibling search tools for events and games. However, it does not explicitly contrast with alternatives or mention the venue scope, so it falls just short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for finding venues but provides no explicit guidance on when to use it instead of search_events or search_games. There are no exclusions, prerequisites, or alternative tool references, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 20, 2026

Changedregister_user3 fields changed

changedInput schema / properties / email / description

Previous value: -"Email address (will receive a verification mail)"New value: +"Optional. The person's real email, only if they gave you one. Omit it rather than inventing one — they set it when claiming."

changedInput schema / properties / password / description

Previous value: -"Password, minimum 8 characters"New value: +"Password, minimum 8 characters. Generate a strong random one; the person replaces it when they claim."

changedInput schema / required

Previous value: -[
-  "email",
-  "password",
-  "name",
-  "lastName",
-  "tosAccepted"
-]New value: +[
+  "password",
+  "name",
+  "lastName",
+  "tosAccepted"
+]

6 tool updatesApr 28, 2026
- First observedcreate_event
- First observedregister_user
- First observedrsvp_event
- First observedsearch_events
- First observedsearch_games
- First observedsearch_venues

Related MCP Connectors

Fantasy Tabletop Helper
io.github.kushaim
Read-only access to your tabletop campaigns: codex, sessions, and session notes.
Games & Gamification Note Taking Knowledge & Memory
1
agendaforge A
app.agendaforge
Event management for organizers: events, sessions, speakers, agendas, forms, approval-gated writes.
Project Management App Automation
551
SessionKeeperOAuth
ai.sessionkeeper
Dungeons & Dragons (D&D) and TTRPG companion: SessionKeeper sessions, NPCs, wiki, DM prep.
Games & Gamification Note Taking
2
MinkOAuth
com.minkapp
Discover local events, RSVP, and manage organizer workflows on Mink.
Calendar Management Location Services Project Management
1

Related MCP Servers

ddb-mcp
Games & Gamification
Doogan1
A
license
Not graded
quality
C
maintenance
Enables MCP-compatible clients to read D&D Beyond characters, campaigns, and game reference data, with optional opt-in tools for session tracking and character building.
Updated 14 days ago (2026-09-08 03:08 UTC)
MIT
Foundry REST API MCP
Games & Gamification
zagushka
A
license
C
quality
A
maintenance
Enables preparing Foundry worlds and running encounters through the FoundryVTT REST API Relay, with tools for managing worlds, scenes, encounters, and table play.
Updated 2 months ago (2026-08-01 16:04 UTC)
53
MIT
EvHenter MCP
Search Content Management Systems
doffpett
F
license
Not graded
quality
D
maintenance
An event aggregation platform that enables users to search, retrieve, and create event data using a Sanity.io backend. It provides specialized tools for managing event details, locations, categories, and venues through the Model Context Protocol.
Updated 8 months ago (2026-01-22 08:25 UTC)
-
Lorcana Event Finder
Games & Gamification Search
zammitt
A
license
Not graded
quality
D
maintenance
An MCP server that lets AI assistants look up Disney Lorcana TCG events, stores, and tournament data via the Ravensburger Play API.
Updated 5 months ago (2026-04-23 10:21 UTC)
45 npm
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?