Skip to main content
Glama
untappd-mcp

untappd-mcp

by chrischall

Get a brewery's beer list

untappd_brewery_beers
Read-onlyIdempotent

Retrieve a brewery's beers by ID, including global rating, check-in count, ABV, style, and availability, with sorting and paging; cached lists can answer without extra API calls.

Instructions

Get the beers a brewery makes, by brewery id, with per-beer global rating, check-in count, ABV, style and in_production. Supports sorting and paging. Get an id from untappd_search_brewery. Lists are CACHED locally for 7 days (source:"cache"|"api", fetched_at, expires_at): a fresh cached list answers without an API call — the default popularity order from the cached top-of-list, other sorts once the whole list is cached (sorted locally). refresh:true re-fetches. The compact result has the same keys with or without the cache (source:"api" and null fetched_at/expires_at when no cache is available), with pagination {offset, limit, next_offset}. Untappd's per-beer has_had / your-count on this endpoint describe the AUTHENTICATED account, never the user you are asking about, so have_had / your_count are never cached or returned on either path — use untappd_cache_has_had_many for any user. With the cache, the result carries favorite {is_favorite, sources, reason} for the brewery and on each favorite beer (derived from username's history or added with untappd_favorite_add; default your account). view:"full" always calls Untappd and returns its raw page. Read-only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brewery_id": "<brewery_id>"
    },
    "name": "untappd_brewery_beers"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNoSort order (default by popularity)
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact keeps each beer's identity, rating and counts and drops the description, label URLs and the copy of this brewery repeated on every row; "full" returns Untappd's whole page (always fetched live).
limitNoMax beers (1–50, default 25)
offsetNoResult offset for paging (default 0)
refreshNoRe-fetch from Untappd even if a fresh cached list exists (default false)
usernameNoWhose favorites to mark (cache only; default your configured account)
brewery_idYesUntappd brewery id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.6.1
    • addedInput schema / properties / refresh
      Added value: +{
      +  "description": "Re-fetch from Untappd even if a fresh cached list exists (default false)",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / username
      Added value: +{
      +  "description": "Whose favorites to mark (cache only; default your configured account)",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / view / description
      Previous value: -"Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact keeps each beer's identity, rating and counts and drops the description, label URLs and the copy of this brewery repeated on every row; \"full\" returns Untappd's whole page."New value: +"Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact keeps each beer's identity, rating and counts and drops the description, label URLs and the copy of this brewery repeated on every row; \"full\" returns Untappd's whole page (always fetched live)."
  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. Changed1 schema field changedv1.11.0
    • addedInput schema / properties / view
      Added value: +{
      +  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact keeps each beer's identity, rating and counts and drops the description, label URLs and the copy of this brewery repeated on every row; \"full\" returns Untappd's whole page.",
      +  "enum": [
      +    "compact",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  4. Addedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the 7-day local cache, the source/fetched_at/expires_at markers, the pagination envelope {offset, limit, next_offset}, and the important caveat that Untappd's has_had/your_count reflect the authenticated account and are never cached or returned. It does not describe rate limiting or error behavior when the brewery id is unknown, which is why this is a 4 rather than 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?

Purpose is front-loaded in the first clause and every subsequent sentence carries substantive cache, paging or account-scoping information. It is dense and parenthetical-heavy, and the closing 'Read-only.' merely restates the readOnlyHint annotation, but there is very little genuine padding.

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 7-parameter tool with a two-path (cache vs live) execution model and no output schema, the description covers return shape, cache metadata fields, pagination, and the favorite annotation structure. An agent can call it correctly and interpret the response without further documentation.

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%, so the schema already documents every parameter including enums, bounds and defaults; baseline is 3. The description does add real semantics the schema lacks — that sorting is local once the full list is cached, that refresh:true bypasses the cache, that view:"full" forces a live call, and that username only affects favorite marking on the cache path — but these are stated in prose rather than tied explicitly to each parameter.

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?

Opens with a specific verb and resource — 'Get the beers a brewery makes, by brewery id' — and immediately enumerates the per-beer fields returned (rating, check-in count, ABV, style, in_production). This clearly separates it from untappd_brewery_info (brewery metadata) and untappd_search_beer (lookup by name).

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?

Explicitly routes the agent to untappd_search_brewery to obtain the id, states that a fresh cached list answers without an API call and when sorts become local, and specifies refresh:true for re-fetching and view:"full" for a live raw page. It even names the correct alternative for the has_had question (untappd_cache_has_had_many).

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