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.

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.

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.

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.

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.

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.

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

The description explicitly states 'Read-only,' matching the readOnlyHint=true annotation, and adds useful behavioral context beyond annotations: the feed is limited to friends' check-ins, sorted newest first, and pages backwards with max_id. It does not mention authentication or rate limits, but the annotations already establish the safety profile.

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

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

The description is three short sentences that front-load the core purpose, then add useful scope/order details, paging instructions, and a safety note. Every sentence earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only feed tool with no output schema, the description adequately conveys that the result is a newest-first list of friends' check-ins and references pagination metadata. The input schema fully documents parameters. It could be more explicit about the full response envelope, but the pagination.max_id reference and view parameter description cover the essentials.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 operational meaning beyond the schema by explicitly instructing the agent to page backwards using max_id from a prior call's pagination.max_id, which clarifies the parameter's role in a multi-call flow.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb phrase ('Get your Untappd friend activity feed') and defines the resource as 'recent check-ins from people you follow', with ordering 'newest first.' This clearly differentiates it from siblings like untappd_user_checkins or untappd_trending without requiring their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear context: this is the authenticated user's friend activity feed, not a user, venue, or local feed. It also explains how to page through results by instructing to use max_id from a prior call's pagination.max_id. It stops short of explicitly naming alternatives or when not to use the tool, so I deduct one point.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already provide readOnlyHint, and the description adds useful behavioral context: the data is public, the response includes specific check-in fields, and max_id must be sourced from pagination.max_id in a prior call. This goes beyond the annotation while remaining consistent with it.

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

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

Two tight sentences: the first states the operation and payload, the second gives paging guidance. No filler, and the most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 the essential return content, scope, and paging behavior. Parameter defaults and view options are already documented in the schema, so nothing critical is missing for selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 extra meaning by explaining the cross-call relationship for max_id, which is not fully captured by the schema's generic 'Return check-ins older than this id' phrasing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: get recent public check-ins for a beer by bid. It also describes what the response includes (who drank it, rating, comment, venue), clearly distinguishing it from beer_info, user_checkins, and other sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Clearly establishes this is the beer-scoped check-in activity tool and gives explicit paging instructions using max_id from a prior call. It does not name alternatives or when-not-to-use scenarios, but the context is strong enough for an agent to route correctly.

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

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

The description discloses a behavioral contingency the annotations don't: recent activity is only returned on view:full, so a default compact call silently excludes it. The schema adds depth by explaining this is a server-side drop of the activity block, not a local projection. The annotations (readOnlyHint, idempotentHint, openWorldHint) are consistent with the Read-only line, so there is 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.

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

The description is three short sentences, front-loaded with the verb-resource-fieldlist sentence and followed by actionable sourcing guidance. The only waste is the trailing Read-only fragment, which merely duplicates the readOnlyHint annotation — a minor redundancy in an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only lookup with no output schema, the enumerated field list substitutes for return-value documentation and tells the agent exactly what it will receive. The view parameter's effect on response shape is fully documented in the schema, and the sourcing instruction closes the loop on the required bid. Nothing needed to call the tool correctly — input source, default behavior, conditional output — is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100 percent, so the bid type/bounds and the view enum with its detailed compact-versus-full explanation already carry the semantic load; the baseline is 3. The description adds workflow meaning the schema lacks by telling the agent to get a bid from untappd_search_beer, grounding the parameter in an agent-reachable source. The recent-activity-on-full note reinforces view semantics already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence pairs a specific verb and resource — Get full detail for a beer by its Untappd beer id (bid) — and enumerates the returned fields: description, style, ABV, IBU, brewery, rating, check-in count, and recent activity on full view. This distinguishes it from the search sibling, and the instruction to source the bid from untappd_search_beer makes clear this tool resolves a known id rather than performing search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The line 'Get a bid from untappd_search_beer' is explicit workflow guidance, telling the agent how to obtain the required bid parameter before calling. It clearly implies the tool's niche — detail lookup for a known id — but never names when-not cases, such as preferring untappd_beer_activity for activity-only needs instead of view:full.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds useful behavioral context beyond annotations: it specifies the response content (per-beer rating, check-in counts) and that sorting and paging are supported. 'Read-only' is redundant with annotations but not contradictory.

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

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

Three short sentences, front-loaded with the core purpose, followed by supported features and a practical source for the required identifier. No wasted words or repetition beyond the redundant 'Read-only'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with complete schema coverage and rich annotations, the description is sufficient. It tells the agent what data to expect, that pagination/sorting exists, and where to obtain a valid brewery_id. No essential calling information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all five parameters including enums, defaults, and response-shape differences. The description only lightly re-mentions sorting and paging, adding no meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get the beers a brewery makes, by brewery id, with per-beer rating and check-in counts.' This clearly distinguishes the tool from brewery metadata tools like untappd_brewery_info and beer-specific tools like untappd_beer_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides a clear prerequisite workflow: 'Get an id from untappd_search_brewery.' It also implies when to use the tool based on the brewery-id input, though it does not explicitly state when not to use it or compare it to sibling tools.

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

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

Annotations already carry readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds value beyond annotations by enumerating the return payload (description, location, type, rating, check-ins, popular beers), and its 'Read-only' statement agrees with the readOnlyHint annotation — 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.

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

Two sentences with zero waste: the primary purpose and field list are front-loaded, followed by the id-source chain and a one-word safety marker. Every sentence earns its place relative to the sibling-heavy context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderate-complexity tool (2 params, 1 required, no output schema) in a family of 40+ siblings, the description covers what it returns, how to get the id, and that it is safe. The only notable gap is not explicitly routing agents to untappd_brewery_beers when they need the full beer catalog rather than popular beers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with brewery_id and the view enum both fully described, so the baseline is a strong 3. The description adds one genuinely useful semantic beyond the schema: the provenance of brewery_id ('Get an id from untappd_search_brewery'), which tells the agent how to obtain a valid value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get full detail for a brewery by its Untappd brewery id') plus the exact fields returned (description, location, type, rating, total check-ins, popular beers). This distinguishes it from untappd_search_brewery (id lookup) and untappd_brewery_beers (beer list) without needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a concrete usage chain: 'Get an id from untappd_search_brewery' tells the agent the required precondition and where the parameter value comes from. It does not explicitly exclude alternatives such as untappd_brewery_beers when the full beer list is needed, but the word 'popular' scopes the beers claim.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already provide readOnlyHint=true, and the description's 'Read-only' reinforces rather than extends that signal. It adds a useful temporal behavior ('recent', 'right now') but does not disclose response shape, pagination, rate limits, or auth requirements. With the safety profile covered by annotations, this is adequate but not rich.

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

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

The description is compact and front-loaded, stating the core action and location scope in the first clause. The em-dash clarification and optional-radius note add value without bloat, and 'Read-only' is short even if redundant with annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only location query, the description plus the fully documented schema are sufficient to invoke the tool correctly. The 'view' parameter already explains the response shape, and the description covers purpose, location, and optional radius. No output schema exists, but the schema's view description compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with detailed descriptions for lat, lng, view, limit, and radius. The tool description only mentions lat/lng and radius, duplicating schema content rather than adding new meaning. Baseline 3 applies because the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get recent check-ins') and a precise resource/scope ('near a location (lat/lng)'), and clarifies the intent with 'what people are drinking nearby right now.' This clearly distinguishes it from sibling tools like untappd_checkin_info and 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.

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

The description makes the use case clear: retrieving recent, location-based check-ins with an optional radius expansion. It does not explicitly name alternative tools or state when not to use it, but the 'near a location' and 'right now' framing provides sufficient contextual guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint and idempotentHint; the description confirms read-only and adds that results are ranked matches. However, the description claims the response includes global rating, while the view parameter's default compact projection omits that field — only 'full' includes it. This slight inconsistency makes the behavioral claim less reliable.

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

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

Three concise sentences with the core purpose front-loaded, a useful alternative hint, and a one-word behavioral tag. No filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, together with a 100%-covered schema and detailed view explanations, covers search scope, sorting, paging, and output shape. The main gaps are the rating inconsistency and the lack of an explicit pointer to the brewery-search sibling, but these are minor given the clear sibling names and schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already explains sort, view, limit, offset, and query. The description contributes extra query-format guidance ('Brewery Beer') and summarizes the returned fields, going beyond the baseline without duplicating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: search Untappd for beers by name, optionally in 'Brewery Beer' format. It lists the returned fields and explicitly routes to untappd_beer_info for full detail, clearly distinguishing it from the untappd_search_brewerry sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear context: use when you need to find beers by name, and it points elsewhere (untappd_beer_info) once you have a bid. It does not explicitly state when not to use it or name untappd_search_brewerry as the alternative for brewery searches, so it stops short of perfect routing guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral detail beyond those: the returned set is deduplicated ('distinct (unique)'), scoped to all-time check-ins ('ever checked in'), and includes per-beer rating and check-in count. It also restates 'Read-only', which is redundant but consistent.

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

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

The description is compact and front-loaded, with the core purpose in the first sentence and usage notes in the second. The trailing 'Read-only' duplicates the annotation, which is minor redundancy in an otherwise tight description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description conveys the essential return content (distinct beers, ratings, counts) and the key call behavior (sorting, paging, optional username). Combined with the fully documented schema and safety annotations, nothing critical is missing for an agent to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter already documented including enums, defaults, and the username fallback to UNTAPPD_USERNAME. The description's 'Omit username for your own account' adds no new signal beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Get the distinct (unique) beers a user has ever checked in,' with rating and check-in count per beer. This clearly distinguishes it from siblings like untappd_user_checkins (raw checkin feed) and untappd_user_wishlist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear usage context: it is for a user's distinct checked-in beers, supports sorting and paging, and explicitly says to omit username for your own account. It does not name alternatives or when-not-to-use conditions, but the intent is clear.

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

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

Annotations already carry readOnlyHint, openWorldHint, and idempotentHint, and the description's 'Read-only' merely reinforces those. It adds genuinely new behavioral context: results are ordered most-recent-first, max_id acts as a backward cursor sourced from a prior call's pagination.max_id, and the payload includes beer/rating/comment/venue/toast data — none of which is encoded in 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.

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

Three short sentences with the core purpose front-loaded; the paging rule and the username-default rule each get their own sentence, and the 'Read-only' tag is a single word. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned fields, and the schema's view parameter text fills in the compact/full projection difference. Paging flow and username defaulting are fully covered; only edge behavior (empty results, errors, rate limits) is left undisclosed, which is acceptable for a read-only cursor-paged endpoint with rich annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 four parameters and the view enum's compact/full projection detail. The description adds one operational nuance beyond the schema: max_id is not just an id filter but the pagination.max_id cursor returned by a prior call. That modest addition keeps it at the high-coverage baseline rather than above it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Get a user's recent check-ins') with an ordering guarantee (most recent first) and enumerates the returned content (beer, rating, comment, venue, toasts/comments). This makes it distinguishable from user-profile siblings like untappd_user_info, untappd_user_beers, and untappd_user_badges without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides concrete usage rules: page backwards by passing the pagination.max_id from a prior call, and omit username to target the configured account. It stops short of naming alternatives or stating when not to use it (e.g., untappd_checkin_info for a single check-in), so it lacks explicit exclusion guidance.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the 'Read-only' mention is redundant. The description adds the behavioral nuance of omitting username for the configured account and enumerates return content, but it doesn't disclose error handling or rate-limit behavior.

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

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

The description is three short sentences with the main verb and resource front-loaded. Each sentence earns its place: purpose, usage hint, safety note. No filler or redundancy beyond the minor 'Read-only' repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description names the expected return fields, giving an agent a clear idea of the response. The two optional parameters are fully explained in the schema, and the sibling list provides enough context for routing. Only explicit alternative-tool routing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both 'view' and 'username' already carry detailed descriptions in the schema. The tool description's 'Omit username for your own account' repeats the schema text, so it adds no new semantic value beyond the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get an Untappd user's profile') and enumerates the exact contents (bio, location, total check-ins, distinct beers, badges, stats). This clearly distinguishes it from sibling user_* tools that return detailed check-in or badge lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context about what this tool returns (a profile summary) and gives the key usage instruction to omit username for your own account. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's 'Read-only' adds no new information. It does add the useful behavioral note about sorting and paging, and hints at identity handling by saying 'Omit username for your own account,' but it does not discuss rate limits, response shape beyond the schema, or other side-effect-related behavior.

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

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

The description is short and front-loaded with the core purpose. The only minor redundancy is the final 'Read-only' sentence, which repeats information already present in the annotations. Otherwise, every sentence is concise and contributes a distinct idea.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, paged list tool with no required parameters and full schema coverage, the description provides sufficient operational context: what it returns, that it supports sorting and paging, and how to target the caller's own account. The lack of an output schema is partially mitigated by the 'view' parameter's detailed explanation of both compact and full response shapes. The main gap is the absence of guidance on when to prefer this tool over a sibling like untappd_user_beers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description only restates that sorting and paging are supported and that the username is optional, adding little beyond the structured parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Get') and a specific resource ('beers on a user's wishlist'). This clearly identifies the tool's function and distinguishes it from the many sibling tools such as untappd_user_beers or the wishlist add/remove operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides no guidance about when to use this tool versus alternatives. It mentions that the username can be omitted for one's own account, but does not explain how this tool relates to sibling user tools like untappd_user_beers or when one would choose the wishlist over other beer-listing endpoints.

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

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

The readOnlyHint and openWorldHint annotations already cover safety and scope; the description adds meaningful behavior beyond them: it states the results are public, includes ratings/check-in content, and specifies that paging is backwards via a prior call's pagination.max_id. It does not detail auth or rate limits, but the annotation coverage lowers the bar and the added context is useful.

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

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

Three short, high-signal sentences: the main action with result contents, the paging mechanism, and the read-only flag. There is no filler or repetition of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only venue check-in listing, the description conveys the core result contents and paging behavior, and the schema fully documents all parameters including view/limit behavior. With no output schema, a bit more response-envelope detail could help, but the description is sufficient for correct selection and basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 an extra practical detail for max_id—pointing to pagination.max_id from a prior call—and orients the agent around what the returned check-in records contain. This is a small but genuine increment beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Get the recent public check-ins at a venue by its id," and names the outcome data (who was there, what they drank, ratings). This clearly distinguishes it from venue search/info siblings and from user/beer/brewery activity tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It establishes clear context: call by venue_id, returns public check-ins, and explicitly explains how to page backwards using max_id from the prior pagination.max_id. It does not name alternative tools or say when not to use it, so it misses the top score.

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

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.

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.

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.

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.

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.

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.

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, covering safety behavior. The description adds 'Read-only' and explains the data scope, but it does not disclose additional behavioral traits such as rate limits, caching, or the meaning of openWorldHint beyond what annotations carry. It does not contradict the annotations, but also does not substantially extend them.

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

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

The description is compact and front-loaded with the core action ('Get full detail'), followed by the key return fields and the id-sourcing hint. Every sentence earns its place, and the 'Read-only' note is a useful quick signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately lists the main returned fields and the effect of the 'full' view. It also explains how to obtain the required id. It does not cover every potential edge case or error condition, but for a read-only detail lookup with a well-covered schema, the context is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 useful semantic guidance by pointing to untappd_search_venue as the source for venue_id, and by clarifying the effect of the 'full' view on the returned detail. This exceeds baseline without duplicating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get full detail for a venue by its Untappd venue id'), lists the fields returned, and clearly distinguishes itself from search-oriented siblings. It also names untappd_search_venue as the upstream id source, making its role in the family obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear usage context: use this when you already have a venue id and want detailed venue information. It points to untappd_search_venue for obtaining the id, but it does not explicitly state when not to use related tools like untappd_venue_activity or untappd_venue_menu. This is clear context without exclusions, so a 4 is appropriate.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.