untappd-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.8.6
Disambiguation5/5
Each tool has a clear, distinct purpose with descriptive names. The cache tools are clearly differentiated from live API calls, and search vs. detail tools are unambiguous. No overlapping tools.
Naming Consistency5/5
All tools follow a consistent 'untappd_verb_noun' pattern in snake_case. Verbs like search, info, add, remove, sync are used uniformly, making the intent clear at a glance.
Tool Count4/5
44 tools is a large set, but it comprehensively covers the Untappd API domains: user, beer, brewery, venue, check-ins, social, wishlist, and caching. While on the high side, each tool serves a distinct purpose and the set is well-organized.
Completeness4/5
The tool surface covers CRUD for check-ins, wishlist, friends, comments, and toasts, along with extensive read-only queries and caching. Minor gaps exist (e.g., no check-in editing, no user profile update), but core workflows are fully supported.
Average 4.3/5 across 44 of 44 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 22 of 22 community issues answered or closed in the last 6 months
- 97 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; description adds 'Read-only' and lists notification types. No additional behavioral traits (e.g., rate limits, authentication) are mentioned, but the bar is lower due to annotations.
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?
Single sentence with no wasted words. Front-loaded with purpose and efficiently lists notification types.
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 list tool with 2 optional params and no output schema, the description provides sufficient context about the content (notification types). Could mention result structure but not critical.
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 baseline is 3. Description adds no extra meaning beyond the schema's parameter descriptions.
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 states the verb 'Get' and resource 'Untappd notifications' with specific types (toasts, comments, etc.) and scope 'YOUR account'. It is clear but does not explicitly differentiate from siblings like untappd_activity_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context such as prerequisites, exclusions, or comparison with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the ordering behavior ('most recent first'), which is useful, but does not disclose other behavioral traits such as rate limits, authentication requirements, or response format. With annotations covering the readonly nature, the description adds moderate value.
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 extremely concise with three short, front-loaded sentences. Every sentence adds distinct value: what it does, ordering, and usage hint. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain the structure of returned data. It mentions badges and ordering but omits details like pagination, badge representation, or field descriptions. Given the tool's simplicity (3 optional params, well-documented schema), this is adequate but not fully complete.
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 description coverage is 100%, so the baseline is 3. The description adds valuable usage context for the 'username' parameter ('Omit for your own account') and the ordering hint, which goes beyond the schema. This extra guidance raises the score.
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 states the tool retrieves user badges ordered by most recent. While it distinguishes from sibling tools by focusing on the 'badges' resource, it does not explicitly differentiate from other user-specific list tools like untappd_user_beers or untappd_user_checkins.
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 provides a specific usage instruction: 'Omit username for your own account.' However, it lacks guidance on when to use this tool versus alternative tools, nor does it mention any prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds 'Read-only' which repeats the annotation. It also mentions omitting username for your own account, which is also in the parameter schema. No additional behavioral traits beyond annotations are disclosed.
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 extremely concise: two short sentences covering the essential purpose and a key usage note. No wasted words. Excellent structure for quick comprehension.
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 simplicity, the description covers the basic purpose and a usage nuance. It is suitable for a read-only list tool with well-documented parameters. Could add a note about pagination or result format, but not strictly required.
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 parameters. The description adds no new parameter semantics beyond what is in the schema (e.g., the omit username note is duplicated). Baseline score of 3 is appropriate.
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 states the tool retrieves a user's friend list ('Get a user's friend list'). It distinguishes from sibling tools like untappd_user_checkins or untappd_user_beers by specifying 'friend list'. However, it could be more explicit about when to use this vs other user data tools.
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 provides a usage hint ('Omit username for your own account') but does not explicitly compare with alternative tools or state when/not to use this tool. No direct guidance on context relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context: 'Read-only' reinforces safety, and 'Omit username for your own account' reveals authentication-related behavior. No contradiction.
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 sentences, front-loaded with the action, no wasted words. Every sentence adds value.
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 two optional parameters, no output schema, and annotations present, the description is nearly complete. It covers purpose, key data fields, and a usage hint. Minor gap: no explanation of default behavior when both parameters are omitted.
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%, both parameters have descriptions. The tool description restates the 'omit username' hint but does not add new meaning beyond the schema. Baseline score of 3 is appropriate.
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 states the verb and resource: 'Get an Untappd user's profile' and lists the data fields (bio, location, total check-ins, distinct beers, badges, stats). It helps identify the tool's purpose and distinguishes it from sibling tools like untappd_user_badges and untappd_user_beers, though not explicitly.
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 provides a usage hint: 'Omit username for your own account.' This gives contextual guidance but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral details (most recent first, per-venue counts, supports sorting/paging) but does not disclose failure modes or authorization requirements beyond the username hint. Moderate added value.
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 three sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words. Appropriately sized for the tool's complexity.
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 no output schema and 4 optional parameters, the description covers ordering, counts, paging, and the special username case. However, it lacks guidance on error conditions (e.g., if user not found) or rate limits. Most core aspects are addressed.
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 baseline is 3. The description adds context for username ('Omit for your own account') and implies usage of sort/paging, but does not elaborate on enum values or limit semantics beyond what the schema provides.
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 ('Get') and resource ('venues a user has checked in at'), with additional details on ordering and counts. The title reinforces this. Among siblings like untappd_venue_activity and untappd_venue_info, the purpose is distinct and clear.
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 provides a useful guideline ('Omit username for your own account') but does not explicitly state when to use this tool versus alternatives like untappd_venue_activity or untappd_venue_info. The 'Read-only' hint is implied but not contrasted with mutable tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Read-only' adds minimal value. It does not disclose additional behaviors such as pagination, rate limits, or error conditions. The description adds some context about real-time data but not enough to fully inform.
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 sentences: first states main function, second adds optional radius and read-only nature. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return format. It says 'what people are drinking nearby' but does not specify structure (e.g., list of check-ins with details). Appropriately assumes agent understands check-in concept, but could be more explicit.
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 baseline is 3. The description mentions 'Optionally widen the search radius' for the radius parameter but provides no additional meaning for lat, lng, limit, or compact beyond what is in the schema.
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 retrieves recent check-ins near a location using lat/lng, specifying it shows what people are drinking nearby. It distinguishes itself from sibling tools like untappd_checkin (for posting) and untappd_user_checkins (for user-specific checkins).
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 indicates the tool is read-only and optionally allows widening search radius, but does not explicitly list when to use versus alternatives. However, the purpose is clear enough for an agent to choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the description need not repeat those. The description adds value by stating 'Read-only' and listing the returned fields, but it does not disclose any additional behavioral traits (e.g., rate limits, authentication needs). No contradictions with annotations.
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 sentences, front-loaded with the core purpose, and no wasted words. Every sentence adds value: first states the tool's function and output, second explains how to get the required input. Perfectly concise.
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?
Without an output schema, the description compensates by listing the key return fields (description, location, type, rating, total check-ins, popular beers). It also connects to the search tool. Could mention potential limitations (e.g., number of popular beers), but overall it is sufficient for an agent to use 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 coverage is 100% with descriptions for both parameters: brewery_id and compact. The description does not add significant meaning beyond the schema—it implies the default is full detail, but that is already clear from the schema description of compact. Baseline 3 is appropriate.
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 action ('Get full detail') and the resource ('brewery by its Untappd brewery id'), and lists the specific data returned (description, location, type, rating, total check-ins, popular beers). It also distinguishes from sibling tools like untappd_search_brewery by explaining how to obtain the id.
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 explicit context for usage: obtain the brewery id from untappd_search_brewery. It clearly indicates the tool is read-only. While it does not explicitly state when not to use it, the context is sufficient, and the sibling tool list provides alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it is read-only (redundant) and explains the compact toggle's impact on output. Some additional behavioral context beyond annotations, but not extensive.
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 sentences with no wasted words. First sentence states purpose and output fields; second sentence provides ID source and notes read-only nature. Information is front-loaded and efficient.
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 no output schema, the description enumerates key return fields (category, address, etc.) and explains the compact parameter's effect. This is sufficient for a simple read-only venue detail tool, though could mention venue name or other common fields.
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 both parameters. The description adds value by explaining the compact parameter's effect on the output (slimmer record without embedded activity), which goes beyond the schema's field description.
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 retrieves full venue details by ID, listing specific return fields (category, address, contact, rating, check-ins, and optionally top beers/activity). It distinguishes from sibling tools like untappd_search_venue which only returns IDs.
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?
Explicitly states how to obtain the venue ID via untappd_search_venue and notes the compact parameter's effect. While it doesn't explicitly list when not to use, the read-only nature and ID requirement provide clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description states 'Read-only,' which is consistent but adds no new behavioral context beyond the annotations. No contradictions.
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 sentences with no redundant words. Front-loaded with the primary action and resource, followed by essential context. Every sentence serves a purpose.
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 low-complexity tool with a single parameter and no output schema, the description fully covers purpose, parameter source, and read-only nature. No gaps.
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% and the description implicitly references the parameter ('by its id'), but does not add additional meaning beyond what the schema already provides for checkin_id. Baseline score 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?
The description clearly states the verb 'Get', the resource 'single check-in detail', and lists specific fields included (beer, rating, comment, etc.). It distinguishes from sibling tools like untappd_activity_feed and untappd_user_checkins which serve different purposes.
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 tells the agent how to obtain the required checkin_id ('from a feed or user-checkins result'), providing clear context for usage. It does not explicitly state when not to use, but for a single-item retrieval, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool modifies real data, describes dry-run behavior, and notes the endpoint is not independently verified. Annotations already indicate readOnlyHint=false and idempotentHint=true, and description adds further context beyond annotations.
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 sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values or preview structure, but it doesn't. However, it covers purpose, behavior, and parameter usage adequately. Lacks details on what the dry-run preview or success/failure responses look like.
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 baseline is 3. The description adds minimal extra meaning beyond the schema's parameter descriptions, such as confirming the boolean behavior, but it does not significantly enhance understanding.
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?
Description clearly states the tool rejects/ignores incoming friend requests and references untappd_pending_friends for pending uids, distinguishing it from siblings like untappd_accept_friend.
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?
Explains that it acts on the user's account and affects real relationships, with a dry-run mode using confirm parameter. References untappd_pending_friends for finding target uids, providing context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only', aligning with the readOnlyHint annotation. It also describes pagination behavior with max_id. No additional behavioral traits (e.g., rate limits) are mentioned, but the annotations already provide safety info, so the description adds value beyond the schema and annotations by confirming the pagination pattern.
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 extremely concise: two sentences totaling 24 words. It front-loads the main purpose and includes essential usage details without any filler. Every sentence serves a clear purpose.
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 simplicity (3 params, no output schema), the description covers purpose, ordering, pagination, and safety. It lacks a brief note on the response structure (e.g., that it returns a paginated list of check-ins), but the annotations and context signals provide enough for an agent to infer behavior. It is nearly complete.
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 covers all three parameters with descriptions (100% coverage). The tool description adds context by associating max_id with pagination from a prior call, but this is a minor enhancement over the schema description. Therefore, the baseline of 3 is appropriate.
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 verb 'Get' and the resource 'your Untappd friend activity feed — the recent check-ins from people you follow, newest first'. This distinguishes it from sibling tools like untappd_beer_activity or untappd_local_checkins by specifying it's for the friend feed. The pagination detail adds further clarity.
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 implicitly tells when to use the tool: to view the friend activity feed. It also explains how to page backwards using max_id. However, it does not explicitly exclude alternatives or provide guidance on when not to use it, which would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'Read-only' and mentions per-beer rating and check-in counts as behavioral traits. Annotations already declare readOnlyHint, idempotentHint, and openWorldHint; description enriches without contradiction.
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 sentences only: first covers purpose and key outputs, second gives prerequisite. No wasted words, front-loaded with critical information.
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 list endpoint with no output schema, description covers purpose, required parameter source, parameter behaviors, and safety. Mentions output fields (rating, check-in counts). Lacks paging metadata details but overall sufficient.
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% and includes descriptions for all four parameters. The description briefly references sorting and paging but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
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?
Clearly states 'Get the beers a brewery makes' with specific verb and resource, includes output details (per-beer rating, check-in counts), and distinguishes from siblings like untappd_brewery_info or untappd_beer_info by focusing on the list.
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?
Explicitly says 'Get an id from untappd_search_brewery' to obtain the required brewery_id, and notes 'Read-only' to indicate safe usage. Does not explicitly list alternatives among siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the tool combines two operations and returns { resolved, detail }, providing behavioral context beyond the annotations.
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 front-loaded action—no unnecessary words. Every sentence serves a purpose.
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 a single parameter and no output schema, the description sufficiently explains purpose, behavior, and relationship to siblings. Minor omission: does not specify expected URL format (e.g., requiring https://), but not critical.
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 a single parameter description. The tool description repeats the same information without adding extra detail about URL format or constraints. Baseline 3 applies as schema carries the burden.
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 it resolves an untappd.com URL and fetches entity details in one call, explicitly distinguishing it from sibling tools untappd_resolve and the various info tools by calling it a convenience combination.
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 explains it is a combination of two tools and is read-only, implying when to use it (when both resolution and detail are needed). It does not explicitly state when not to use or list alternatives, but the context of sibling tools provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds value by stating 'Read-only' and specifying the return format, which matches annotations and provides behavioral context beyond annotations.
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 concise sentences, front-loaded with purpose, no unnecessary words or redundant information.
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?
No output schema is provided, but the description covers the return fields adequately. Annotations and schema sufficiently describe the tool for its low complexity (search by name with paging). Minor gap: no mention of pagination behavior beyond offset/limit.
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 descriptions for all parameters. The description does not add additional parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 it searches for breweries by name and lists the returned fields (id, location, type, beer count). It distinguishes from sibling tool untappd_brewery_info by suggesting that tool for full detail.
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?
Description explicitly advises using untappd_brewery_info for full detail, providing a clear alternative. However, it does not cover when not to use this tool versus other search tools (e.g., search_beer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context by noting the split into macro/micro lists, going beyond annotations which only indicate read-only and open-world hints.
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 sentences, front-loaded with purpose, no unnecessary 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?
The description adequately explains the main output (two lists) for a simple trending tool, though no output schema is provided.
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?
No parameters exist, so schema coverage is 100%. The description clarifies the output structure, earning a baseline of 4 for zero-param tools.
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 retrieves trending beers split into macro and micro lists, distinguishing it from sibling tools like beer info or search.
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 getting trending beers, but does not explicitly state when to use or avoid it compared to alternatives like untappd_search_beer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds valuable context: 'Supports sorting and paging' and specifies that results include 'rating and check-in count per beer.' This goes beyond what annotations convey, but does not detail all behavioral aspects like rate limits.
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?
The description is three sentences: purpose, capabilities, and usage hint. It is front-loaded with the core function and wastes no words. However, it could be slightly tighter by merging the last two sentences, but still very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should compensate by describing the return format more thoroughly. It mentions 'rating and check-in count per beer,' which gives some insight, but lacks details on pagination response structure, error handling, or how the compact parameter affects output. Partially complete.
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 baseline is 3. The description adds meaning to the 'compact' parameter by explaining it projects a slim summary with specific fields (bid, name, brewery, etc.), and clarifies that 'username' can be omitted for the own account. This adds value beyond the schema.
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 it 'Get[s] the distinct (unique) beers a user has ever checked in, with their rating and check-in count per beer.' This specific verb-resource combination distinguishes it from sibling tools like untappd_user_checkins (individual checkins) and untappd_beer_info (single beer details).
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 a clear directive: 'Omit username for your own account.' This tells the agent when to omit the parameter. It also mentions 'Supports sorting and paging,' which guides usage. However, it does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the 'Read-only' statement and explains pagination direction and default ordering, which goes beyond the annotations by detailing operational behavior.
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 sentences with no redundancy. The main purpose is front-loaded, and every phrase adds value (ordering, content, pagination, user hint).
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?
Despite no output schema, the description adequately summarizes the return fields (beer, rating, comment, venue, toasts/comments). It mentions pagination metadata (max_id) implicitly. Could be more explicit about the response structure, but sufficient for a list retrieval tool with a standard resource.
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 each parameter. The description reinforces the purpose of max_id and the username omission rule but adds marginal new meaning beyond the schema.
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 verb 'Get' and the resource 'user's recent check-ins', specifying what is included (beer, rating, comment, venue, toasts/comments) and ordering (most recent first). It distinguishes from sibling tools like untappd_checkin_info or untappd_beer_activity by focusing on the user's timeline.
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?
Provides explicit pagination guidance ('Page backwards with max_id') and a conditional usage hint ('Omit username for your own'). Does not explicitly exclude alternative tools, but the context is clear enough for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds sorting/paging capability and account behavior, which are useful beyond annotations. No contradiction.
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 covering purpose, features, and usage tip. No wasted words, front-loaded with key action.
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 read-oriented tool with no output schema, the description covers parameters and behavior adequately. Could explain response structure more, but the compact parameter hints at summary fields.
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 description adds no new parameter information beyond what is already in the schema. The mention of sorting/paging is implied by parameters but not new detail.
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?
Clearly states 'Get the beers on a user's wishlist', identifying the verb and resource. Distinguishes from siblings like untappd_wishlist_add and untappd_wishlist_remove by implying read-only, and mentions sorting/paging.
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?
Provides context for sorting, paging, and omitting username for own account. Implicitly differentiates from mutation sibling tools, but lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by detailing the dry-run behavior when confirm is false (no network call) and the actual write when confirm is true. This complements the annotations (readOnlyHint=false, idempotentHint=true) without contradiction.
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 very concise with three sentences: purpose, parameter behavior, and effect. All content is necessary and front-loaded with the primary action.
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 covers the key nuance (preview mode) and is complete given the tool's simplicity. It lacks mention of error handling or idempotency implications, but overall sufficient for an agent.
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 clear parameter descriptions. The tool description adds minimal extra meaning beyond stating 'by its bid' and reiterating the confirm behavior already in the schema.
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 verb 'Add', the resource 'beer to YOUR Untappd wishlist', and the identifier 'bid'. It is specific and distinguishes from siblings like untappd_wishlist_remove.
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 explains the use of the 'confirm' parameter, providing clear guidance on when to use the tool for a dry-run preview versus actual addition. It implies a cautious approach with writes but does not explicitly mention alternatives for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds 'Read-only' and clarifies it covers incoming requests, but does not disclose further behavioral details such as auth requirements or rate limits. Given strong annotations, this is adequate.
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 efficient sentence plus 'Read-only', front-loading the key purpose. No redundant information.
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 read-only tool with comprehensive annotations and no output schema, the description adequately explains what the tool returns (incoming friend requests). It is complete given the tool's simplicity.
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%, and the parameters (limit, offset) are fully described in the schema. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'incoming friend requests waiting on YOUR account', distinguishing it from siblings like untappd_user_friends which likely shows confirmed friends.
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 implies using this tool to view pending friend requests, but does not explicitly state when not to use it or mention alternatives. However, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. Description adds 'Read-only' and specifies return fields, providing value beyond annotations without contradiction.
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 sentences, each essential. Front-loaded with purpose, no redundant information, highly efficient.
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?
Given simple search tool, no output schema, annotations cover safety, description fully covers purpose, return fields, and next step. Complete for 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 coverage is 100% so credit given. Description adds 'by name' which aligns with query param but no additional value for limit. Baseline 3 is appropriate as schema does the heavy lifting.
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?
Clearly states verb (search), resource (venues) with examples (bars, breweries, restaurants), and specifies returned data (venue id, category, location). Differentiates from sibling tools like untappd_search_beer.
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?
Explicitly mentions feeding venue id to untappd_venue_info for full detail, guiding next steps. Lacks explicit when-not-to-use but contextually clear it's for venue search exclusively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description reinforces 'Read-only' and adds pagination behavior (page backwards). No contradictions. The description adds context beyond annotations without repeating them.
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 efficient sentences: first states core purpose, second explains pagination. No unnecessary words, front-loaded, perfectly sized.
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?
No output schema exists, but description lists returned fields (rating, comment, venue) and pagination detail. For a 4-parameter list tool, this sufficiently informs the agent of return structure and behavior.
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 covers 100% of parameters with descriptions. Description adds specific usage for max_id, clarifying it expects the pagination.max_id from a prior call. This improves understanding over schema alone.
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 gets recent public check-ins for a beer by bid, including specific data fields (who drank, rating, comment, venue). This distinguishes it from siblings like untappd_beer_info (beer details) and untappd_checkin_info (single check-in).
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?
Explicitly describes pagination using max_id from prior calls. Does not specify when to avoid this tool versus alternatives, but the purpose is distinct enough. Could add exclusion criteria, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond annotations (readOnlyHint, idempotentHint): it explains the tool uses cached data, checks both sources, returns had/not-had with count and date, and flags freshness. No contradiction with annotations.
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 very concise: three sentences with clear front-loading of purpose, then details, then usage guidance. No redundancy.
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 simplicity (2 params, no output schema), the description covers purpose, behavior, return format, prerequisite, and freshness. Minor gap: return structure details slightly vague, but sufficient for typical 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 the baseline is 3. The description adds context like 'list of beer ids' for the bids parameter and optional account for username, but does not provide significant extra meaning beyond the schema.
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 verb 'cross-check' and resource 'beer ids against a user's cached history', and distinguishes from siblings by emphasizing batch capability and no API call.
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 recommends using this tool for checking a whole venue menu and mentions a prerequisite (run untappd_sync_user_beers first). It implies when to use but does not explicitly state alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=false) already indicate non-read-only and non-idempotent. Description adds specific behaviors: dry-run mode with confirm=false and that it posts to public feed, enhancing transparency.
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 clear, front-loaded sentences. No redundancy or wasted words. Efficiently communicates the core purpose and key parameter usage.
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?
Covers main functionality, required parameter, optional parameters, and dry-run mechanism. Lacks details on return format (e.g., what the dry-run preview contains or successful response structure), but given no output schema, it provides sufficient context for the agent to decide and invoke the tool.
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 covers all parameters with descriptions (100% coverage). Description adds value by specifying that bid is obtained from untappd_search_beer, rating in 0.25 increments, photo_path expects local JPEG/PNG, and confirm's behavior. These details help the agent use parameters correctly.
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?
Description clearly states the action (post a beer check-in), the resource (Untappd account), and the effect (publishes to public feed). It distinguishes from siblings like untappd_delete_checkin and untappd_checkin_info.
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?
Explains that to post, use this tool with confirm=true, and that a dry-run preview is available without confirm. Mentions that bid comes from untappd_search_beer. However, lacks explicit exclusions for when not to use (e.g., for viewing check-ins use other tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses destructive irreversible behavior ('Permanently delete...This is destructive and cannot be undone') and the confirm parameter's role as a safeguard. Annotations already indicate non-readOnly and idempotent, and description adds crucial context about the dry-run feature, which annotations do not cover. No contradiction with annotations.
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 sentences that are direct and front-loaded. Every word is needed: the action, the destructiveness, the confirm parameter's dual behavior. No fluff.
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?
Tool has no output schema, so description must cover key behavior. It explains the delete action, the dry-run mechanism, and the irreversible nature. It doesn't specify the return value (e.g., success message or deleted object), but for a delete tool, that is less critical. The ownership of the check-in is implied by 'YOUR'.
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%, providing a baseline of 3. The description adds value by explaining the 'confirm' parameter's effect (dry-run vs actual delete) beyond the schema's simple 'boolean' description. For 'checkin_id', the description is minimal ('Untappd check-in id'), but the schema already covers it.
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?
Description clearly states the action: 'Permanently delete one of YOUR check-ins by its id.' The verb (delete), resource (check-in), and ownership (YOUR) are explicit, distinguishing it from sibling tools like untappd_delete_comment.
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?
Description explains the dry-run preview behavior (without confirm:true) and the actual deletion (with confirm:true), guiding the agent on safe usage. It doesn't explicitly state when not to use (e.g., not for others' check-ins), but the 'YOUR' qualifier implies that restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it explains the dry-run behavior when confirm is false and the actual deletion when confirm is true. The annotations (readOnlyHint=false, idempotentHint=true) are consistent with the description. However, the description does not detail what happens if the comment does not exist or if the user is not the owner, which would further improve transparency.
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 extremely concise, consisting of two sentences. The first sentence states the purpose and the second explains the confirm parameter behavior. Every word is necessary and there is no extraneous information.
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 has only two parameters and no output schema, the description covers the essential behavior: what it does, how to use it safely with the confirm parameter, and where to get the comment_id. It is mostly complete, though it could explicitly mention that only the user's own comments can be deleted and what the expected success response looks like.
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 schema covers both parameters with descriptions (comment_id and confirm). The description adds critical semantic value for the confirm parameter by explaining the dry-run vs actual deletion behavior, which is not fully captured in the schema description. For comment_id, the description reinforces the source (from a check-in's comments list) similarly to the schema.
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 that the tool deletes one of the user's own comments, using the comment id. It uses a specific verb ('Delete') and resource ('your comments'), and distinguishes itself from siblings like 'untappd_add_comment' and 'untappd_delete_checkin'.
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 clear guidelines on how to use the confirm parameter: without confirm:true it is a dry-run preview and makes no network call; with confirm:true it deletes. This informs the user about safe usage and the required step to actually delete. It implies that the tool should only be used for the user's own comments, but does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, idempotent, and open world. The description adds important behavioral context: 'Acts on YOUR account and affects a real relationship with another person' and the caveat about the endpoint not being independently verified. This goes beyond what annotations alone provide.
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 concise, with core action stated first, followed by essential behavioral details and a caveat. Every sentence adds value without redundancy.
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 two parameters and no output schema, the description covers the key aspects: action, dry-run behavior, parameter semantics, and a reliability note. It could briefly mention that the user must have an existing relationship, but overall it's sufficiently complete.
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%, but the description adds meaning: for confirm, it explains the dry-run vs actual execution; for target_uid, it specifies the source ('from a user profile or friends-list item'). This supplements schema descriptions.
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 specific verbs ('Removes', 'cancels') and identifies the resource ('existing friend', 'friend request'). It clearly distinguishes from sibling tools like untappd_add_friend and untappd_accept_friend by focusing on removal/cancellation.
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 explains the confirm parameter behavior, guiding when to use true vs false (dry-run preview). It does not contrast with alternatives like rejecting a friend request, but the context is clear from the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that results are ranked and includes specific fields, and explicitly says 'Read-only', which aligns with annotations. No contradictions.
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, front-loaded with the action and key details, with no unnecessary 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?
With no output schema, the description covers return fields and mentions ranking. It also points to a sibling tool. However, it doesn't discuss pagination or the compact parameter, though the schema covers these sufficiently.
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 has 100% coverage with clear descriptions. The description adds value by noting that the query can be in 'Brewery Beer' format and that results are ranked, which goes beyond the schema's parameter descriptions.
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 'Search Untappd for beers by name', with the optional 'Brewery Beer' format. It distinguishes itself from sibling tools like untappd_beer_info (for full detail) and other search tools for brewery and venue.
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 indicates when to use this tool (to search beers by name) and recommends untappd_beer_info for deeper details. However, it does not explicitly state when not to use or detail alternatives for sorting/pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses toggle behavior, write nature, and visibility to others. Annotations indicate readOnlyHint=false, and description adds that it's a toggle and writes to account.
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 succinct sentences with no fluff, each providing essential behavioral context. Efficient and front-loaded.
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 toggle action, description covers all key behaviors (toggle, dry-run, persistence). Lacks explicit return value description, but acceptable given no output schema.
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 covers 100% of parameters with descriptions. Description adds key operational detail: confirm=true posts, confirm=false is dry-run preview, going beyond schema.
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?
Description clearly states the tool toasts (likes) a check-in on the user's account, using specific verb and resource. Distinguishes itself from sibling tools like untappd_add_comment by being a toggle for liking.
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?
Explains the toggle behavior and dry-run vs. execution with confirm parameter. Provides clear context but does not explicitly mention when not to use or compare to other like-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses real relationship impact, dry-run preview with confirm:false, and unverified endpoint path. Adds context beyond annotations (readOnlyHint=false, idempotentHint=true) without contradiction.
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?
Four sentences, front-loaded with main purpose. Every sentence adds value without redundancy.
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?
Given 2 parameters, no output schema, and annotations present, the description fully covers the tool's behavior and prerequisites. References sibling for pending list.
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?
Adds meaning for confirm (must be true to proceed) and target_uid (source from profile/friend-list). Schema coverage is 100%, but description augments with practical usage instructions.
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?
Description explicitly states 'Accepts an incoming friend request' and references 'untappd_pending_friends' for pending uids. Clearly distinguishes from sibling tools like untappd_reject_friend and untappd_add_friend.
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?
Description tells when to use by referencing pending friends tool and explains the dry-run behavior with confirm flag. Good guidance but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by listing returned fields and explaining compact behavior. Annotations already state readOnlyHint, idempotentHint, openWorldHint, and description aligns with these. No contradictions.
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 efficient sentences: first packs all details, second references sibling tool. No extraneous words.
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, but description fully covers what is returned (list of fields) and effect of compact. Complete for a simple retrieval tool with informative annotations.
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%, baseline 3. Description adds context: 'Get a bid from untappd_search_beer' for bid, and 'unless compact' explains compact parameter effect, surpassing schema alone.
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?
Describes a specific action (Get full detail) on a specific resource (beer by bid), lists contained fields, and distinguishes from sibling tools like untappd_search_beer and untappd_brewery_info.
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?
Explicitly tells how to obtain the bid from untappd_search_beer, and notes the tool is read-only, implying safe usage. Does not explicitly list exclusions, but the context of the tool's simplicity and sibling differentiation suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description reinforces this with 'Read-only' and adds pagination behavior ('page backwards with max_id'), providing useful behavioral context beyond annotations.
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 two sentences: one for core purpose and returned data, one for pagination and safety. It is front-loaded with the verb 'Get' and contains no filler, making it highly efficient.
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?
Despite lacking an output schema, the description explains what the response contains (who, what they drank, ratings). Pagination behavior is covered. Given the tool's moderate complexity (4 parameters, no nested objects) and the presence of annotations, the description is sufficiently complete.
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?
Parameter schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the pagination intent of max_id and implicitly describing limit's default (though schema already states default 25). This enhances understanding beyond the schema alone.
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 it retrieves recent public check-ins at a venue by ID, specifying the returned data (who, what they drank, ratings). This distinguishes it from sibling tools like untappd_venue_info or untappd_checkin_info that return different resources.
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 explicit pagination guidance ('page backwards with max_id') and declares the tool read-only. However, it does not explicitly state when to use this tool over similar ones like untappd_local_checkins or untappd_activity_feed, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description confirms read-only and adds the mapping behavior. No contradictions, and while it doesn't add extensive new details, it consistently reinforces the safe, idempotent nature.
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 sentences that efficiently convey purpose and usage guidance. No wasted words; front-loaded with the core action.
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 simple single-parameter tool with no output schema, the description fully covers what the tool does, when to use it, and its safe read-only behavior. No additional information is needed.
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?
Input schema covers 100% of parameters with a clear description for foursquare_id. The description does not add extra semantic detail beyond the schema, so baseline 3 is appropriate.
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 a specific verb 'Resolve' and clearly identifies the resource: Foursquare venue id to Untappd venue. It distinguishes itself from siblings like untappd_venue_info and untappd_venue_activity by indicating it provides the needed venue ID.
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 states when to use the tool: to convert a foursquare_id for use with untappd_venue_info or untappd_venue_activity. Also marks operation as read-only, which helps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond annotations: it mentions the dry-run behavior, the requirement of 'confirm: true' for actual removal, and that it writes to the account. Since annotations only provide readOnlyHint=false and idempotentHint=true, the description adds significant value.
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 two sentences with no wasted words. The first sentence immediately states the purpose, and the second explains the confirm parameter. It is front-loaded and efficient.
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 removal tool, the description covers the key aspects: what it does, how to use the confirm parameter, and the dry-run preview. It could mention the return value of the preview, but given the idempotent annotation and no output schema, it is fairly complete.
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 by linking 'bid' to 'untappd_search_beer' and explaining that 'confirm: true' is necessary for execution, reinforcing the schema information.
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 'Remove a beer from YOUR Untappd wishlist by its bid.' It uses a specific verb (remove) and resource (beer from wishlist), and it distinguishes itself from sibling tools like untappd_wishlist_add which performs the opposite action.
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 explains when to use the confirm parameter: without it, the tool returns a dry-run preview; with it, the removal proceeds. However, it does not explicitly state when not to use this tool or mention alternatives, but the sibling context provides sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false. The description adds valuable context: the dry-run behavior (no network call without confirm), that it writes to the account, and that comments are visible to others. No contradictions.
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 two sentences, front-loading the purpose and then providing key behavioral details. Every sentence adds value without redundancy.
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?
Given the tool has 3 parameters and no output schema, the description fully covers the behavior: dry-run mode, actual posting, visibility, and account context. No gaps are apparent.
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 schema describes all 3 parameters with 100% coverage, so baseline is 3. However, the description adds meaning to the 'confirm' parameter by clarifying its role in dry-run vs actual posting, which goes beyond the schema.
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 verb 'post a comment' and the resource 'check-in from YOUR account', distinguishing it from other Untappd tools. The nuance about dry-run vs actual posting is explicit.
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 explains when to use 'confirm: true' versus 'without confirm: true', providing a dry-run preview option. No explicit when-not or alternative tools mentioned, but for a simple tool this suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the dry-run preview behavior, network call condition, and the real relationship impact. It also notes the endpoint path is not independently verified, adding transparency.
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 three sentences long, front-loaded with the main action, and every sentence provides essential information without redundancy.
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?
While the description covers the action and key behaviors, it does not specify return values or error states. Given no output schema, an agent might need more guidance on what a successful response looks like, but the description is still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for both parameters, and the description adds crucial context about the confirm parameter's behavior (dry-run vs execution), making the semantics very clear.
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 it sends a friend request to another user, using specific verb and resource. It distinguishes from sibling tools like untappd_reject_friend, untappd_remove_friend, and untappd_accept_friend.
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 explains when to use the tool (to send a friend request) and the role of the confirm parameter (dry-run vs actual action). It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cache-only operation (no API call), consults both cached sources, and returns not-had bids plus had bids and counts. Annotations confirm read-only and idempotent; description adds detailed behavioral traits beyond annotations.
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 sentences with no extraneous words. Purpose is front-loaded, necessary details follow efficiently.
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?
Covers inputs, outputs (despite no output schema), prerequisites, and limitations (freshness caveat). Adequately complete for an agent to use correctly.
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% with descriptions for both params. Description adds meaning by explaining the filter purpose and that the return includes 'the not-had bids (plus the had bids and counts) and cache freshness'.
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?
Clearly states 'return only the ones the user has NOT had' with the analogy 'what here is new to me? filter'. Differentiates from sibling cache tools like untappd_cache_has_had.
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?
Explicitly advises to run untappd_sync_user_beers first for accurate results and warns about false negatives with incomplete coverage. Does not list sibling alternatives explicitly but context implies when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond readOnlyHint: cache-only nature, no API call, and difference in cache window for self vs. other accounts. No contradiction with annotations.
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 concise sentences, front-loaded with main purpose. Every sentence adds value with no redundancy.
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 query tool with no output schema, description explains what results reflect, data source limitations, and prerequisite sync. Adequately complete.
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 covers all 11 parameters with descriptions (100% coverage). Description lists filter categories but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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?
Clearly states action (query), resource (cached check-ins), and filters (brewery, style, etc.). Distinguishes from sibling tools like untappd_cache_has_had/not_had.
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 states it is cache-only with no API call, explains cache limitations for non-self accounts, and advises running untappd_sync_checkins first. Also suggests alternative tools for full coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true. The description adds that it is offset-paged, resumable, persists progress, and feeds cache tools. No contradictions. It could mention the mutation to cache more explicitly.
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?
Four sentences front-loaded with purpose, each sentence adds essential information. No redundant 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?
No output schema, but description explains fetched data and resumable nature via another_run_needed. Could be slightly more explicit about return fields, but sufficient for a sync tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context: username can be omitted for own account, max_pages defines pages of 50 beers each (default 10) and should be modest due to rate limits, going beyond schema.
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 specifies the verb 'Fetch', the resource 'a user's COMPLETE distinct-beers list', and details the data (rating, times-had, first/last dates). It distinguishes from siblings like untappd_sync_checkins and mentions feeding cache tools.
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 states it's the cheapest way to get full 'has had' coverage, contrasts with user/checkins (pages fully for public/friend accounts), advises to omit username for own account, and suggests keeping max_pages modest due to rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains behavioral traits: caching behavior, API call conditions (cache miss, age >30 days), rate limiting, partial results with re-running, and freshness reporting. This goes well beyond annotations.
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?
Concise yet thorough. Front-loads with purpose, then details behavior in a logical flow. Every sentence adds necessary information.
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?
Given no output schema and moderate complexity, the description covers all important aspects: input, caching, API calls, rate limits, partial outputs, and freshness. It is complete for an agent to invoke correctly.
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 covers all 5 parameters with descriptions. The description adds value by stating defaults (top_n: 2, api_budget: 25) and explaining style substring matching, which enriches the schema.
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 identifies the tool as the 'what should I order off this tap list?' tool, specifying it returns top-rated beers not yet had from a candidate list. It distinguishes from siblings like untappd_cache_not_had by focusing on ranking and candidate list.
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?
Provides clear context for when to use (order from a tap list) and a usage tip (omit username for own account). However, it doesn't explicitly compare to similar tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description goes beyond by stating 'Pure local parsing — no network' and 'Read-only', confirming the safety profile. It also reveals that it outputs the entity type, id, and the next tool to call, which is a behavioral trait not in annotations.
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 two sentences long, front-loaded with the main action ('Parse an untappd.com URL...') and essential constraints ('Pure local parsing — no network. Read-only.'). Every word adds value; no redundancy.
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?
Despite no output schema, the description explains the return value (entity type, id, and next tool to call). It covers constraints (local, read-only, no network). For a single-parameter tool with straightforward behavior, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes only one parameter 'url' with a generic description. The description adds significant meaning by enumerating the accepted URL formats: /b/, /w/, /v/, /user/, and check-in links, which helps the agent construct valid inputs. Schema coverage is 100%, and the description compensates fully.
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: parse an untappd.com URL into entity type and id, and name the next tool to call. It specifies the URL types (beer, brewery, venue, user, check-in). This distinguishes it from sibling tools which are actions, not resolvers.
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 clear usage context: it's a parser for untappd URLs, local and read-only. It implicitly tells when to use (when you have a URL), but does not explicitly state when not to use or compare with alternatives among siblings. However, its unique role as a resolver makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description details the incremental/resumable nature, paging backwards, progress persistence, another_run_needed flag, rate limit consideration, and behavior for other users' accounts. It also explains force_backfill effects.
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?
The description is a single paragraph that is reasonably concise given the complexity. It could benefit from slight structural breaks (e.g., bullet points) but every sentence adds value and it is not overly long.
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 (stateful sync, rate limits, special cases), the description covers most aspects: operation, repeatability, limitations for other users, and force_backfill. However, it lacks mention of error handling or output format details, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: username omission for own account, max_pages rate limit advice, and force_backfill clarification. This goes beyond the schema descriptions.
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: fetching detailed check-ins into a cache. It specifies the resource (user's check-ins), the operation (sync, incremental and resumable), and distinguishes from sibling tools like untappd_sync_user_beers, which is for full coverage.
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 provides when-to-use and when-not: it warns about limitations for other users' accounts and directs to use untappd_sync_user_beers for full coverage. It also explains the force_backfill use case and recommended max_pages for rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, and idempotentHint. The description adds critical behavioral details: it walks sections with a configurable page budget (max_pages), does NOT loop to completion in one call (respects rate limit), returns another_run_needed and next_section_offset for resumability, and explains the truncated flag for upstream issues.
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?
The description is well-structured with key purpose upfront, followed by problem statement, solution details, and resumability explanation. It is informative but slightly verbose; a few sentences could be tightened without losing clarity.
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?
Given the tool's complexity (6 parameters, pagination, resumability, no output schema), the description fully covers what the tool does, how it behaves under constraints, and the output structure. It provides all necessary context for correct invocation and interpretation of results.
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 provides 100% description coverage for all 6 parameters. The description adds operational context beyond the schema: clarifies max_pages as a budget per run (not page size), explains how section_offset is used for resumption, and mentions that sort is optional. This adds moderate value.
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 returns a venue's verified beer menu as a flat list, and distinguishes itself from untappd_venue_info by explicitly noting that sibling only returns the first section, leading to under-reporting. The output format and resumable behavior are described.
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?
The description explains when to use this tool instead of untappd_venue_info (when complete menu is needed across multiple sections). It also advises getting the venue id from untappd_search_venue and describes the call budget and resumable logic, guiding efficient usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no API call, consults two cached sources, reports per-source freshness, and caveats incomplete data—valuable beyond annotations which already mark readOnlyHint and idempotentHint.
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?
Efficient, front-loaded with core purpose, each sentence adds value, no fluff.
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?
Given complexity of caching and no output schema, description fully covers return values, prerequisites, and data freshness logic.
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% (baseline 3), but description adds that either bid or beer_name is required and explains beer_name as case-insensitive substring match, providing extra clarity.
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?
Clear verb-check+resource+cache, explicitly distinguishes from siblings like untappd_cache_has_had_many and untappd_cache_not_had by specifying single beer check from cache.
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 states to use cached data only, advises running untappd_sync_user_beers first for full coverage, implies alternative for fresh data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is read-only, lightweight, and performs an authenticated request. Reports exact outputs (success, server version, tool count/hash/names). Annotations (readOnlyHint, idempotentHint, openWorldHint) are consistent. No contradictions.
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. First sentence states primary purpose. Second sentence adds output details. No redundant or vague phrasing.
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?
Fully covers what the tool does, its read-only nature, and what it returns (success, version, tool list). No output schema exists, but description explains expected outputs. Annotations provide additional context.
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?
No parameters (input schema empty), so baseline is 4 per rules. Description adds context about the behavior (authenticated request, what is reported) beyond the empty schema.
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 verifies Untappd connectivity and credentials, and reports server version and exposed tools. It uses specific verbs ('verify', 'performs') and distinct resource ('Untappd connectivity, credentials'). Among 42 sibling tools, none duplicate this healthcheck function.
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 describes when to use (to verify connectivity and credentials) and what it does (lightweight authenticated request, reports success, version, tool set). No exclusions needed as it's a standalone diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![untappd-mcp MCP server](https://glama.ai/mcp/servers/chrischall/untappd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/untappd-mcp)

Score Badge

Copy to your README.md:

[![untappd-mcp MCP server](https://glama.ai/mcp/servers/chrischall/untappd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/untappd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/untappd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server