Skip to main content
Glama
chrischall

untappd-mcp

by chrischall

Get Untappd user badges

untappd_user_badges
Read-onlyIdempotent

Retrieve the badges a user has earned on Untappd, sorted most recent first. Specify a username or omit to view your own badges, with optional limit and offset for pagination.

Instructions

Get the badges a user has earned, most recent first. Omit username for your own account. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax badges (1–50, default 25)
offsetNoResult offset for paging (default 0)
usernameNoUntappd username. Omit to use your own configured account (UNTAPPD_USERNAME).

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. First observedv0.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description reinforces the read-only status without contradiction. It adds genuine value beyond the annotations by disclosing result ordering ('most recent first') and the self-account omission behavior, which are behavioral facts not captured in the structured fields.

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?

Three short, purposeful clauses with zero waste. The purpose is front-loaded, followed by the single non-obvious usage nuance (self-account omission) and the safety profile. Every word 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?

For a simple paginated read tool with all parameters documented in the schema and three strong annotations, the description covers purpose, ordering, and account handling. No output schema exists, so return-value explanation isn't required. The only minor gap is not mentioning pagination behavior, but limit/offset are already fully specified in the schema.

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% with informative descriptions for all three parameters (limit range/default, offset default, username falling back to the configured UNTAPPD_USERNAME). The description largely restates the username behavior already present in the schema, so it adds minimal meaning beyond the structured data — the baseline 3 applies.

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?

Uses the specific verb 'Get' with a concrete resource ('badges a user has earned') plus the ordering qualifier 'most recent first'. Among the large sibling family (user_info, user_checkins, user_wishlist, user_beers, user_friends, user_venues), 'badges' is a distinct resource, so an agent can unambiguously distinguish this tool 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 Guidelines3/5

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

The description clarifies the key usage nuance — 'Omit username for your own account' — which guides when to include the parameter. However, it never explicitly names alternatives or states when not to use this tool versus the other user_* siblings; the differentiation relies on the tool name itself being self-evident rather than on explicit routing guidance.

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