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

With no annotations, the description carries the full disclosure burden. It usefully reveals what the tool inspects (iCloud Drive and the snapshot file state), but never states that this is a non-mutating read/diagnostic, nor what form the explanation takes. Safety profile and side-effect behavior are left unstated.

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 what the tool does and how, the second states when to invoke it. Every clause earns its place and the purpose 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?

For a zero-parameter diagnostic with no output schema, the description omits the return shape — an agent cannot tell whether it yields a diagnosis only, or a diagnosis plus remediation. What it does and when to use it are covered, but the result contract 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?

The tool takes zero parameters, so per the baseline this scores 4. The description correctly implies no inputs are needed by describing a self-contained environment check.

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 outcome ("Explain why the Swizzler library is missing or not updating") plus the resources inspected (iCloud Drive, snapshot file). It does not explicitly contrast itself with the closest sibling, snapshot_status, so an agent must infer the boundary from the word "Explain".

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 an explicit trigger condition: "Use when recipes are missing or stale." That is clear context for invocation, but it names no alternatives or exclusions — e.g. when to prefer snapshot_status or recipe_history instead.

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?

No annotations are provided, so the description carries the full burden. 'Full details' plus 'user's library' implies a read scoped to the caller's data, but nothing is said about what happens if the name/id is not found or whether lookup is case-sensitive.

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?

A single front-loaded sentence with no waste; the resource and lookup keys come first and nothing is padded.

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 one-parameter read tool with no output schema, the description conveys the scope and the return ('full details'), which is nearly sufficient. It could say more about the shape of the returned details, but nothing critical to invocation 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 the description only restates 'by name or id', which the schema already documents. Baseline 3 applies since the schema does the heavy lifting and the description adds no format or matching semantics.

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 (get) and resource (recipe) with scope ('one recipe in the user's library') and lookup keys ('by name or id'). This clearly separates it from list/search siblings like search_recipes, though those siblings are not named explicitly.

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?

Usage is implied: fetch full details when you already know which recipe you want. There is no explicit when-to-use/when-not guidance or routing to search_recipes for fuzzy lookups, leaving the agent to infer the boundary.

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?

With no annotations, the description carries the full burden. 'List' clearly signals a read-only, non-mutating operation and discloses the salient return content (collections plus per-collection recipe counts), which is genuinely useful. However, it says nothing about ordering, pagination, empty-result behavior, or any auth requirement.

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?

A single front-loaded sentence with no filler; every clause (resource, ownership scope, returned metric) earns its place.

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 trivial, parameterless read tool with no output schema, the description conveys both what is listed and the shape of the result (collections with recipe counts), which is enough to call it correctly. Minor gaps around ordering and auth requirements keep 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?

The tool takes zero parameters, so the schema has nothing to document and the description has nothing to compensate for. Baseline for a parameterless tool is 4.

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 ('List the user's recipe collections') and adds scope detail (recipe counts per collection). It does not explicitly name a sibling to distinguish from, but the resource is distinct enough from get_recipe, search_recipes, and whats_next that confusion is unlikely.

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?

Usage is implied rather than stated: an agent can infer this is for surveying collections, but there is no explicit when-to-use, when-not-to-use, or pointer to search_recipes/get_recipe for drilling into contents. No prerequisites are given.

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?

No annotations exist, so the description carries the full behavioral burden. It discloses the data source ('Made It' history) and that ratings are included, which is useful, but says nothing about ordering, pagination, default limit behavior, or whether the result is a full or filtered set.

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 with the resource statement front-loaded and an immediately useful 'use for' clause. No filler, though the second sentence is more illustrative than specification.

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 zero-required-parameter read tool with no output schema, the description adequately conveys what is returned (made recipes plus ratings). It falls short on ordering, defaults, and result shape, which an agent needs to call it 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 only 50%: minRating is described in the schema but limit is bare. The description adds no meaning for either parameter — it does not explain limit's role, default, or ordering, nor clarify that minRating filters on average rating as the schema says.

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 the specific resource: the user's 'Made It' history with their ratings, and gives concrete query examples (most-drunk, highest-rated). It is clearly distinguishable from siblings like search_recipes or what_can_i_make, though it does not explicitly name those alternatives.

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 offers example question types that imply when the tool applies, but never states when NOT to use it or which sibling handles adjacent needs (e.g., searching recipes vs. personal history). Usage is implied rather than routed.

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?

With no annotations, the description carries the full burden; it does disclose the return shape ("one line per match"), which implies a read-only, summarised listing rather than full recipes. It says nothing about pagination, the limit default, or result ordering, and mutability/safety is only implied by "Search".

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 tight sentences with zero filler; the resource scope and filter dimensions come first, the return shape second, and the no-filter behavior last. Every sentence earns its place.

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 search over a well-documented 7-parameter schema with no output schema, the description covers scope, filters, default behavior, and result granularity. Missing only pagination/limit interaction, which the schema largely covers via the limit parameter.

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 seven parameters are already documented, and the baseline is 3. The description adds only the aggregate behavior of omitting filters (list the whole library), which is modest incremental 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?

Specific verb (Search) plus specific resource and scope ("the user's own cocktail library") and the four filter dimensions. It does not explicitly differentiate itself from siblings like get_recipe or what_can_i_make, but an agent can tell it is a multi-result, filter-driven retrieval tool rather than a single-recipe fetch.

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 one concrete usage rule — omit every filter to list the whole library — which is genuinely actionable. However, it never names or contrasts against alternatives (what_can_i_make, get_recipe, whats_next), so the when-to-use-this-vs-that decision is left to inference.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Report' implies a safe read operation and it discloses what is surfaced (freshness and provenance), but it says nothing about whether the check is purely local, whether it can trigger a refresh, or what the response looks like.

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, both load-bearing: the first states what is returned and the second states when to call it. Nothing is repeated from the name or title.

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, no annotations, and no parameters, the description has to convey the value of the call, which it does by naming the two things reported (currency and source) plus the triggering situations. It stops short of describing output shape, but for a parameterless status check this is close to 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?

The tool takes zero parameters, so per the rubric the baseline is 4; there is no parameter behavior left for the description to clarify.

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 gives a specific verb ('Report') and resource ('how current the local Swizzler library snapshot is, and where it came from'), making the read-only diagnostic nature clear. It is distinguishable from siblings like diagnose_sync, though it does not explicitly name any sibling to sharpen the distinction.

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?

Two concrete triggers are given: when the user asks whether recipes are up to date, and when an expected recipe seems to be missing. There are no explicit exclusions or named alternatives (e.g., diagnose_sync), which keeps it 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?

With no annotations, the description carries the full behavioral burden. It never says whether this is a read-only lookup, whether results are ranked, how ties or empty inventories are handled, or what the response contains. The near-miss explanation is useful but is essentially parameter semantics, not behavioral disclosure.

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, zero filler, and the core capability is front-loaded before the modifier parameter tip. Every sentence earns its place.

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-style lookup with no output schema, the description covers the main flow but leaves the limit parameter and result shape entirely unexplained, and with no annotations those gaps are unaddressed elsewhere.

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 67%: ingredients and allowMissing are documented in the schema, and the description usefully extends allowMissing ('see what is missing'). However, the 'limit' parameter is undocumented in both schema and description, and default/format expectations for ingredients are not clarified.

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: find recipes the user can make from ingredients on hand. This implicitly separates it from search_recipes (query-driven lookup) and get_recipe (retrieval by id), but it never names or contrasts those siblings explicitly.

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 second sentence gives a genuine usage cue for the near-miss mode ('Set allowMissing above 0 to include near-misses'), but there is no guidance on when to prefer this over search_recipes or get_recipe, and no prerequisites stated.

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?

No annotations are provided, so the description carries the full behavioral burden. It clarifies what the flagged set represents, but says nothing about ordering, whether it is read-only, or how many items come back. For a no-annotation tool this is partial coverage only.

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, front-loaded with the core concept before the trigger phrases. Nothing is wasted, though the phrasing is slightly indirect by opening with a noun phrase rather than an 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?

With no output schema, the description does well to explain what the returned set represents, and the tool's surface area is small (one optional param). But the undocumented limit parameter is an unaddressed gap, leaving the definition only adequate for correct 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?

The single parameter (limit, 1–100) has 0% schema description coverage and is never mentioned in the description. With no structured documentation anywhere, the agent gets no guidance on what limit means or its default. The description fails to compensate for the coverage gap.

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 resource — recipes flagged "Next Round" — and defines the domain concept (a queue of drinks the user intends to make next). That cleanly distinguishes it from siblings like what_can_i_make (ingredient-driven) and search_recipes. It stops short of a 5 because the verb is implied rather than stated (it is a noun phrase, not '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?

It provides explicit trigger phrases ('what's up next', 'what am I making next', 'what's in my queue'), which is real routing guidance for an agent matching user intent. It does not, however, name the sibling it is not (what_can_i_make) or state any exclusion condition.

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