Skip to main content
Glama
Sign In
untappd-mcp

untappd-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Batch-check many beers against the cache

untappd_cache_has_had_many
Read-onlyIdempotent

Check up to 500 beer IDs against cached Untappd check-in history in one call without API requests, returning had/not-had status and favorites for one user or a group.

Instructions

Cross-check a list of beer ids against a user's cached history in ONE call — NO API call. Consults BOTH sources (check-ins + distinct beers). Returns had/not-had per bid (with count and last date when had), plus favorite {is_favorite, sources, reason} per bid and brewery_favorite when its brewery (from cached beer metadata) is a favorite. Ideal for checking a whole venue menu at once. Pass usernames (instead of username) to check a GROUP: each bid then lists had_by / not_had_by and qualifies per mode — "none_had" (default: new to everyone) or "any_not_had" (at least one of them still needs it) — with qualifying_bids and a per-user freshness block. Run untappd_sync_user_beers first (for every user); the freshness block flags if coverage is incomplete.

Input Schema

NameRequiredDescriptionDefault
bidsYesBeer ids to check (1–500)
modeNoWith usernames: "none_had" (default) keeps beers NONE of them has had (new to everyone); "any_not_had" keeps beers at least one of them has not had.
usernameNoUntappd username. Omit to use your own configured account (UNTAPPD_USERNAME).
usernamesNoCheck a GROUP of users (1–10) instead of one — e.g. everyone at the table. Use instead of username; each must be synced (untappd_sync_user_beers).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.1
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "With usernames: \"none_had\" (default) keeps beers NONE of them has had (new to everyone); \"any_not_had\" keeps beers at least one of them has not had.",
+  "enum": [
+    "none_had",
+    "any_not_had"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / usernames
      Added value: +{
+  "description": "Check a GROUP of users (1–10) instead of one — e.g. everyone at the table. Use instead of username; each must be synced (untappd_sync_user_beers).",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "minItems": 1,
+  "type": "array"
+}
  2. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv1.7.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/closed-world, yet the description still adds substantial behavior: no network call is made, two cache sources are consulted, results include count and last date, favorite/brewery_favorite annotations are returned, and a per-user freshness block flags incomplete coverage. It stops short of explaining edge cases such as what happens for unsynced users or malformed bids, so it is not quite a 5.

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

Conciseness4/5

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

Front-loads the core operation and the 'no API call' guarantee, then layers group mode and prerequisites in logical order. It is dense with em-dashes and parentheticals in a single paragraph, which slightly impedes scannability, but nearly every clause carries information an agent needs.

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?

No output schema exists, so the description carries the return-shape burden and does so: per-bid had/not-had plus count and last date, favorite objects, brewery_favorite, qualifying_bids, and a freshness block. Combined with the sync prerequisite, an agent has enough to invoke and interpret this tool correctly.

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 baseline is 3. The description does add output-level meaning per parameter — the group form produces had_by/not_had_by per bid and drives the mode semantics, and omitting username falls back to the configured account — but it largely restates the mode enum that the schema already documents.

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 — cross-check a list of beer ids against a user's cached history — and adds differentiating scope ('in ONE call — NO API call', both check-ins and distinct beers). An agent can distinguish it from untappd_cache_has_had (singular) and untappd_cache_not_had without opening any schema.

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?

Gives an explicit use case ('Ideal for checking a whole venue menu at once'), a prerequisite ('Run untappd_sync_user_beers first (for every user)'), and a routing rule for the alternative parameterization ('Pass usernames (instead of username) to check a GROUP'). When-not guidance is implicit in the freshness warning, but the selection logic between single vs group mode is fully spelled out.

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

Deploy Server

Other Tools