Skip to main content
Glama
untappd-mcp

untappd-mcp

by chrischall

Check a list of trip stops against a user’s history (cache)

untappd_trip_check
Read-onlyIdempotent

Plan a brewery or bar crawl in one call: check visited venues for you or a group, count beers had at each brewery, and list not-had beers by style and global rating.

Instructions

Plan a brewery/bar crawl in ONE call: for each place (venue_id, name + city/state, lat/lng, and/or brewery_id) return whether the user has been there (dates, total visits, matched venues incl. "(duplicate of …)" copies — from the cached venue history, run untappd_sync_user_venues first), and for a brewery_id: how many of its beers they have had and the top 4 (top_n) NOT-had beers by Untappd global rating, optionally filtered by style (out-of-production beers skipped unless include_out_of_production). Has-had and visits come from the cache ONLY; the only API calls are brewery/beer_list fetches for a brewery whose list is not cached or is past its 7-day TTL, at most api_budget (default 5; 0 = strictly cache-only, a stale list is then used and flagged) under the ~100 calls/hour guard — a missing list sets another_run_needed. Beer lists are global facts: Untappd's have_had on that endpoint is the AUTHENTICATED account's and is never used. Favorites (breweries liked on Untappd via untappd_sync_brewery_likes, derived from the cached history, or added with untappd_favorite_add) are flagged on matched venues, the brewery and beers; prefer_favorites (default true) lifts wishlisted beers (+0.5) and a favorite brewery's beers (+0.25); and a stop within near_favorite_radius_m (default 2000 m) of a favorite venue gets near_favorites + a "Near a favorite" hint. For a GROUP pass usernames + mode ("none_had" default / "any_not_had"). Returns has-had and venue freshness blocks.

Input Schema

NameRequiredDescriptionDefault
modeNoWith usernames: "none_had" (default) lists beers new to everyone; "any_not_had" beers someone still needs
styleNoCase-insensitive substring filter on the beer style (e.g. "ipa")
top_nNoNot-had beers listed per brewery stop (default 4)
placesYesThe stops (1–25); each needs venue_id, name, lat+lng, or brewery_id
usernameNoUntappd username. Omit to use your own configured account (UNTAPPD_USERNAME).
usernamesNoCheck a GROUP (1–10) instead of one user; use instead of username
api_budgetNoMax brewery/beer_list calls for missing or stale lists (default 5; 0 = cache only)
max_matchesNoMost matched venues listed per user per stop (default 5)
prefer_favoritesNoBoost wishlisted beers (+0.5) and favorite-brewery beers (+0.25) (default true)
near_favorite_radius_mNoRadius for the "near a favorite" hint in metres (default 2000)
include_out_of_productionNoAlso rank beers Untappd marks out of production (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses the cache-vs-API split ('has-had and visits come from the cache ONLY'), the exact API exception (brewery/beer_list fetches when uncached or past 7-day TTL), api_budget semantics, the ~100 calls/hour guard, the another_run_needed outcome, and the scoring rules for favorites. These are substantial behavioral details an agent needs to predict results.

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

Conciseness3/5

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

The description is front-loaded and information-dense, but it is one very long, clause-heavy paragraph with semicolons and nested parentheticals that make it hard to parse. It earns its place informationally, but the structure could be broken into clearer sentences or bullets without losing content.

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?

For a complex 11-parameter batch tool with caching, API budgeting, group modes, and favorite-boost logic, the description covers the cache behavior, brewery beer-list fetching, group semantics, scoring, and return blocks ('Returns has-had and venue freshness blocks'). An agent has enough to invoke it correctly and interpret the main outputs.

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 schema already documents every parameter. The description adds value by specifying that top_n returns NOT-had beers by global rating, that prefer_favorites applies +0.5 to wishlisted beers and +0.25 to favorite-brewery beers, and that api_budget=0 means strictly cache-only with a stale list used and flagged.

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 opens with a specific verb and resource: 'Plan a brewery/bar crawl in ONE call' and then enumerates exactly what each stop returns (has-been-there, visits, matched venues, brewery beer counts, top not-had beers). This clearly distinguishes it from single-venue or single-brewery siblings like untappd_venue_info or untappd_brewery_beers.

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?

It gives a clear prerequisite ('run untappd_sync_user_venues first') and a group-checking mode ('For a GROUP pass usernames + mode'). It does not explicitly name a sibling to avoid or state when-not-to-use, but the batch-trip use case is unambiguously established.

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