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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the duplication behavior, the plan_leftover=true flag, optional date/section movement, and that it returns the new event. It does not mention potential side effects like validation failures or permissions, but core behavior is well covered.

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 concise sentences with no filler. The purpose is front-loaded, the behavioral details follow logically, and the return value is stated. Every sentence earns its place; the text is easily parsed and avoids 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 tool with 3 parameters and no output schema, the description adequately covers the primary behavior, the return, and the optional parameters' semantics. It does not mention error handling or prerequisites beyond 'previously planned recipe event,' but that is sufficient for an agent to call it correctly in most scenarios. The absence of an output schema is mitigated by the explicit 'Returns the new event' statement.

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 date and section with descriptions (67% coverage). The description adds meaning for source_event_id by identifying it as the 'source event' from which the leftover is derived. It also clarifies that date and section default to the source event's values, enriching the schema's own descriptions. This goes beyond mere restatement and helps the agent understand parameter intent.

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: schedule a leftover meal derived from a planned recipe event. It explains the mechanism (duplicates source event with plan_leftover=true) and distinguishes it from generic duplication by focusing on the leftover flag and optional date/section changes. This is a specific verb+resource pairing that leaves no ambiguity.

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 context (creating a leftover from a planned event) but does not explicitly contrast with alternatives like duplicate_planner_event or move_planner_event. There is no explicit when-to-use or when-not-to-use guidance, leaving the agent to infer the appropriate scenario from the tool's name and description.

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 provided, the description carries the full burden of behavioral disclosure. It indicates mutation with 'Add' but does not mention side effects, idempotency, or whether the entry appends to existing content. For a simple add operation, this is acceptable, but a more explicit note on behavior (e.g., 'appends to the slot') would 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 a single, front-loaded sentence with an illustrative example. Every word serves to clarify the tool's purpose and parameter roles. There is no redundant 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 simple add operation with no output schema, the description covers the core intent and parameter meanings via the example. It does not restate schema constraints (which are already in the schema), but it provides enough context for an agent to correctly construct a call. Slight gaps remain regarding error behavior or any side effects, but they are minor for this tool type.

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 0%, so the description must compensate. The example '2 lbs ground beef' attached to 'Wednesday dinner' maps implicitly to the title, date, and section parameters respectively. This clarifies the semantic meaning of the three parameters beyond the bare schema, though it does not explicitly name each parameter.

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' and the resource 'freeform ingredient entry to a meal slot', with a concrete example ('2 lbs ground beef' attached to Wednesday dinner). This differentiates it from sibling tools like add_planner_recipe (which likely adds a recipe) and add_planner_note (which adds a note) by emphasizing 'freeform ingredient'.

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 via the example (attaching an ingredient to a meal slot) but does not explicitly state when to use this tool versus alternatives like add_planner_recipe or add_leftover_meal. It relies on the 'freeform' wording to signal a distinction, but there is no explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description must carry the full behavioral burden. 'Add' implies a mutation but the description doesn't disclose what happens on duplicate notes at the same slot, whether it overwrites existing entries, or what the response looks like. For a write operation with zero annotation coverage, this is a meaningful gap.

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?

One efficient sentence with zero filler and a useful example embedded. It earns its space with the concrete scenario, though it could trade some brevity for behavioral detail.

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 3-param tool with a clear example, it's mostly adequate. However, with no annotations and no output schema, it lacks disclosure of edge cases (duplicate handling, response format) that an agent might need. The core call is understandable, 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 0%, so the description must compensate. The example 'Defrost chicken' on Tuesday breakfast' maps loosely to title/date/section, adding some semantic grounding, but it doesn't explicitly explain each parameter's meaning, constraints, or format beyond what the schema already encodes (date pattern, section enum). With 0% coverage, this is insufficient compensation.

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 ('Add') + specific resource ('freeform note entry to a meal slot') with a concrete example. It distinguishes itself from siblings like add_planner_recipe and add_planner_ingredient by emphasizing 'freeform' note, which tells the agent this is for arbitrary text rather than structured data.

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 example implies the use case, but the description doesn't explicitly state when to use this vs alternatives like add_planner_recipe, add_planner_ingredient, or add_leftover_meal. The word 'freeform' weakly hints at distinguishing from recipe/ingredient additions, but there's no explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It does disclose the return value ('Returns the newly created event (id, date, section, servings, ...)'), which is useful since there is no output schema. However, it omits any mention of mutation side effects, idempotency, or failure behavior for a creation tool.

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 the primary action front-loaded and the return-value disclosure following. No wasted words, though the return-value detail could arguably have been folded into the schema.

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 4-parameter tool with no output schema and only 25% schema coverage, the description is moderately complete: it gives the return shape, which is helpful. But recipe_id semantics are left undocumented, and no guidance distinguishes this from the other add_planner_* siblings.

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 only 25% (only frozen_id has a description). The description names date, section, and servings in the return value but does not explain the semantics of recipe_id, which is required and undocumented. It fails to compensate for the low schema coverage.

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 ('add') and resource ('a recipe to a meal slot on the planner'), making the core purpose clear. It does not explicitly differentiate from the similar sibling tools add_planner_ingredient, add_planner_note, and add_leftover_meal, but naming 'recipe' as the payload does implicitly distinguish it.

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 is provided on when to choose this tool over its close siblings (add_planner_ingredient, add_leftover_meal) or when frozen_id should be used instead of recipe_id. The usage context is left entirely 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 must carry the full burden of behavioral disclosure. It only states that it creates a recipe, which is already obvious from the name. It does not mention side effects, authorization requirements, error conditions, or what happens on success, leaving significant gaps.

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 two sentences and no wasted words. It front-loads the core purpose and then adds the most critical parameter details. Every sentence contributes directly to understanding the tool.

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 complexity (27 parameters, no output schema, no annotations), this description is severely incomplete. It does not mention return values, any constraints beyond title, or relationships between fields. An agent would need to infer most behavior from the schema alone, which is insufficient due to low coverage.

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 19%, so the description must compensate. It adds value by explaining that only title is required and clarifying the ingredients array structure. However, it does not elaborate on the other 25 parameters (e.g., fat, url, draft), leaving most parameters unexplained. The description helps for two fields but fails to cover the rest.

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: 'Create a new recipe.' It differentiates from siblings by using the verb 'create' rather than 'update' or 'get', and adds specific details about required title and ingredient structure, making it unambiguous.

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 by stating it creates a new recipe, but it does not explicitly mention when to use this tool versus alternatives like update_recipe or list_recipes. No exclusions or conditions are given, so the guidance is implied rather than explicit.

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?

Fully discloses the soft-delete behavior: the API sets count to 0 and the entry persists as history. This is crucial side-effect information, especially since no annotations are provided.

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 that pack the key information without fluff. The structure is 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?

The description fully explains what happens (soft-delete, count to 0, persistence) for a simple tool with one parameter. No output schema is needed, and the scope is adequately covered.

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 only parameter 'id' has no schema description, and the tool description does not explicitly mention it. However, the action implies the id identifies the frozen entry, so the meaning is inferable but not explicitly added 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?

Clearly states the action (mark a frozen entry as consumed) and the effect (soft-delete, sets count to 0). It is specific to frozen entries, distinguishing it from general delete 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 gives context (eaten or thrown out) but does not explicitly state when to use this tool over alternatives like delete_recipe or delete_planner_event. No direct guidance on choosing this 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?

With no annotations, the description carries the full burden but only says 'delete'; it does not disclose permanence, idempotency, or side 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?

A single, direct sentence with no unnecessary words or 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?

The description is minimally adequate for a simple delete-by-id operation, but it omits operational context such as return behavior, error conditions, and whether deletion is permanent.

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 provides no parameter description, but the phrase 'by id' adds some meaning by indicating that the integer is the identifier of the planner event, though it does not explain how to obtain or validate 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?

Clearly states the action (delete), the target (planner event), and the selection method (by id), distinguishing it from sibling planner tools like move_planner_event and duplicate_planner_event.

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 no guidance on when to use this tool over alternatives or any prerequisites, such as verifying that the event exists before deletion.

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 full responsibility for disclosing behavior. It only states the action and parameter, but does not mention that deletion is irreversible, whether it cascades to related data, requires authentication, or how errors are handled (e.g., non-existent id). This is a significant gap for a mutation tool.

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, direct sentence 'Delete a recipe by id.' It is front-loaded and contains no unnecessary words. Every word 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 delete operation, the description is incomplete. It does not state what happens on success or failure, whether there are side effects, or any return value. Since there is no output schema, the description must cover these aspects, but it does not. The agent is left without critical information for invoking the tool 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?

The schema defines id as an integer with no description (0% coverage). The description says 'by id', which clarifies that the id refers to a recipe identifier, adding meaning beyond the raw schema. However, it does not elaborate on format or constraints, so it only partially compensates for the missing 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 'Delete a recipe by id' clearly states a specific verb (delete) and resource (recipe) with an identifier, distinguishing it from sibling tools like list_recipes, get_recipe, create_recipe, and update_recipe. It is unambiguous about the action and target.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or exclusions, such as whether it is for permanent deletion or if there are related tools like delete_frozen_recipe that should be used in specific cases. The agent must infer usage from the name and context.

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 explains the effect of the optional parameter (plan_leftover) on the copy, indicating that the copy can be marked as leftover. However, it does not specify whether the original event remains unchanged, what the result of the operation is (e.g., new event ID), or any side effects or permissions needed, leaving some behavioral aspects opaque.

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 at two sentences, with no unnecessary words or repetition. It efficiently conveys the core action and the one key parameter behavior.

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 mention what the tool returns (e.g., the duplicated event object or a success indicator). It also omits any preconditions (e.g., whether the original must exist) or postconditions. While the action is simple, the lack of return value or error information makes the description incomplete for an agent to fully anticipate the tool's behavior.

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 has no parameter descriptions, and the tool description only explains the meaning of plan_leftover (marking the copy as leftover). The id parameter is not explained, though it is inferable as the identifier of the event to duplicate. This partial coverage leaves the semantics of id vague, and the description does not fully compensate for the lack of schema documentation.

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 action ('Duplicate') and the object ('a planner event'), which is specific and distinguishable from sibling tools like move or reorder. The use of 'duplicate' leaves no ambiguity about the tool's purpose.

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 does not provide any guidance on when to use this tool versus alternatives such as move or reorder. It only describes the action, not the conditions under which duplication is appropriate, leaving the agent to infer based on the name alone.

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 present, so the description must convey the behavior. The word 'find' indicates a read operation, and the description is straightforward. It does not explicitly state side effects, but none are expected. It could mention what is returned, but for a simple lookup it is sufficiently transparent.

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, concise and free of fluff. It directly states the function and a use case without redundant 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?

Given there is no output schema, the description adequately covers what the tool does and when to use it. The scope (finding events for a recipe, optionally within a date range) is fully described, and the use case adds practical context. No critical 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?

The description links 'given recipe' to recipe_id and 'date range' to start_date and end_date, providing meaning for all three parameters. It also indicates the optionality of the date range. Since the schema provides no per-parameter descriptions, this coverage is valuable and complete.

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 finds planner events for a given recipe with an optional date range. It is specific about the resource (planner events) and the qualifier (recipe and date range), and it differentiates from sibling tools like list_planner_events and get_planner_week by focusing on a particular recipe.

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 a concrete use case: checking if a recipe is already planned this week before scheduling. This gives clear context on when to use the tool, and the optional date range is implied by 'optionally constrained'.

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 explains the core state change—marking portions as frozen—but does not disclose side effects, validation requirements, failure modes, or whether existing frozen entries are updated or duplicated. With no annotations available, the description carries the full burden and only partially meets 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?

The description is concise and front-loaded: the primary action appears first, and the clarifying event_id detail follows in a short second sentence. Every word adds value without unnecessary elaboration.

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 mutation with four required parameters and no output schema or annotations, the description gives a clear purpose but omits practical details like whether the recipe must already exist, whether event_id must reference a valid planner event, and what the tool returns or affects afterward.

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 descriptions already cover count, event_id, and servings, and the description adds useful context about event_id linking to the planner event. However, recipe_id has no schema description and is not explained in the description, leaving one of four required parameters underspecified.

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 a specific action: marking N portions of a previously cooked recipe as frozen. It also defines the role of event_id, tying the frozen entry to a planner event, which distinguishes it from simple leftover logging or frozen-recipe listing.

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 phrase 'previously cooked recipe' implies this should be used after cooking, and the event_id explanation anchors it to a planner event. However, it does not explicitly contrast with sibling tools like add_leftover_meal, list_frozen_recipes, or delete_frozen_recipe, nor state when not to use it.

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

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

No annotations are present, so the description carries the full burden. 'Get' implies a read-only operation, but there is no explicit statement about side effects, errors, or data freshness. It discloses the output categories but not broader behavioral guarantees.

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, short sentence that immediately states the tool's purpose and enumerates the count categories. No filler or redundant wording is present.

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 lack of parameters and output schema, the description adequately explains what the tool returns: counts for friends, queued, and frozen. It could clarify the exact result shape, but the core context is sufficient for a simple count retrieval.

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?

There are no parameters and the empty schema is fully covered. With zero parameters, the baseline is 4, and the description adds no unnecessary parameter detail because none exists.

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 a specific action ('Get') and resource ('recipe-book counts'), and enumerates the three categories returned: friends, queued, and frozen. This distinguishes get_counts from sibling list tools by focusing on counts rather than item 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 implies usage when counts are needed rather than full lists, but it does not explicitly mention when to prefer this tool over sibling tools like list_friends or list_frozen_recipes. No alternative tools are named.

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 read-only behavior ('Fetch'), the default date logic, and the enrichment of recipe events with `recipe_title`. It does not mention error handling or pagination, but provides key behavioral details.

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 deliver all necessary information with no redundancy, efficiently covering functionality and parameter behavior.

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 implies a return of planner events and notes the `recipe_title` enrichment, which is sufficient for basic understanding. It omits return shape and edge cases, but given the simplicity, it's reasonably 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?

Both parameters (`start_date`, `end_date`) are explained with format and the default for `end_date` is given. This fully covers their semantic meaning beyond the schema's pattern constraint.

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 fetches planner events over a date range, with a default week-long window. It distinguishes itself from other planner-related tools by specifying the range and the enrichment behavior.

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 implicitly conveys when to use it (for date-range queries) and the default fallback, but doesn't explicitly contrast with list_planner_events or other siblings. Still, the purpose is evident enough for selection.

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 burden of disclosing behavior. The verb 'get' strongly implies a read-only operation, but the description does not explicitly state that it does not modify data or have side effects. Given the presence of create/update/delete siblings, the read-only nature is inferable but not stated.

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, concise sentence that efficiently conveys the tool's purpose without extraneous words. It includes the resource type, the lookup method, and the expected return content (directions, ingredients, etc.) in a compact form.

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 low complexity (one parameter, no output schema), the description adequately covers what the tool does and what it returns. It does not mention error handling or pagination, but these are not critical for a single-recipe fetch. The description is complete enough 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?

The schema provides only the type and range for the id parameter with no description. The description adds necessary meaning by clarifying that 'id' refers to the recipe's identifier. However, it does not explain the range constraints (min/max) or what happens if an invalid id is provided, though the schema already defines the numeric limits.

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 action (get) and the resource (a single recipe by id), distinguishing it from list_recipes which presumably returns multiple recipes. The inclusion of 'single' and 'by id' makes the purpose unambiguous.

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 implicitly indicates when to use this tool (when you need one recipe by id) versus list_recipes for multiple recipes, but it does not explicitly state 'use this instead of list_recipes when you have a specific id.' The implication is strong enough for a clear 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?

The word 'Get' strongly implies a read-only operation, and mentioning 'sync metadata' hints at the output content. However, it does not spell out whether there are side effects or how the sync metadata is structured. Since no annotations are provided, the description carries the full burden, but the read-only implication is clear.

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, concise sentence that conveys the essential information without any filler. It is well-structured and immediately understandable.

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 no-parameter getter, the description provides sufficient context by naming the resource and the sync metadata aspect. It does not detail the return format or the exact meaning of 'sync metadata,' but this is a minor gap given the simplicity of the tool. The description is adequate for an agent to invoke 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?

The tool takes zero parameters, and the schema is empty with 100% coverage. There is nothing for the description to add about parameters, so a perfect score 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's action ('Get') and the specific resource ('current shopping list') with an additional detail about sync metadata. It is distinct from sibling tools like list_recipes or get_recipe, so there is no ambiguity about its purpose.

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 explicit guidance on when to use this tool versus alternatives, but the purpose is so straightforward that it does not require extensive direction. It names the resource and the read-only nature, which implicitly distinguishes it from mutation 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?

No annotations are provided, so the description carries the full burden. It implies a read-only listing but does not explicitly state safety, auth requirements, or return format. While 'list' inherently suggests no side effects, the description adds no explicit behavioral guarantees beyond the name.

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 concise sentence that front-loads the action and resource. It contains no fluff or redundant information, and every word contributes to the meaning.

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, no-output-schema tool, the description is largely sufficient. It covers the essential purpose and examples. It could optionally mention the return type (e.g., 'returns a list of course names'), but that is implied and not critical for a simple list operation.

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?

There are zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. The schema coverage is 100% (empty schema), so nothing is missing.

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 clear verb-resource pair: 'List all courses' with explicit examples of course types. It is unambiguous and distinguishes itself from sibling list tools (list_recipes, list_cuisines, etc.) by naming a distinct entity.

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 by its name and examples but does not explicitly state when to use it over alternatives or any exclusions. For a zero-parameter list tool, this is acceptable but leaves the agent to infer context from the name alone.

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 provided; description only states the action without noting read-only status, side effects, or error behavior, leaving the agent to infer safety from the verb 'list'.

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 concise sentence with no irrelevant details or 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?

Simple tool with no parameters or output schema; description is adequate but omits any detail on output format, ordering, or possible empty 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?

Schema has zero parameters and description does not need to add parameter semantics; full schema coverage gives a baseline of 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?

States verb 'list' and resource 'cuisines' clearly, distinguishing from sibling list_* tools that target other entities such as recipes, courses, or tags.

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?

Does not explicitly compare to sibling tools or provide when-to-use guidance, but the resource name implies usage when a list of cuisines is needed.

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?

There are no annotations and the description only says 'List friends.' It does not explicitly state whether this is a read-only operation, what the output format is, or any potential side effects. The description is too minimal to fully disclose the tool's 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 extremely concise, consisting of two words. Every word is necessary and no redundant information is present. It is perfectly structured for such a simple tool.

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 is minimal but sufficient for a tool with no parameters and no output schema. It conveys the core function without requiring additional context. A slight improvement could be specifying the return type (e.g., 'Returns a list of friends.'), but this is not essential given the 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?

The tool has no parameters, and the input schema is empty. The description adds no parameter-related information because there is nothing to add. This is appropriate and complete for a zero-parameter tool.

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 'List friends.' clearly states the action (list) and the resource (friends), distinguishing it from sibling tools that list recipes, courses, cuisines, etc. It is unambiguous and specific.

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?

While no explicit alternatives or when-to-use guidance is given, the tool name and description make its purpose self-evident. The context of sibling tools (e.g., list_recipes) implies that this is the appropriate tool for retrieving friends, so no additional guidance is needed.

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 provided, the description fully discloses the tool's behavior: default filtering, the effect of the include_consumed parameter, and the soft-delete design. This is comprehensive for a read-only listing tool.

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 deliver all necessary information without redundancy. The default case is stated first, followed by the optional parameter and its rationale.

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 includes the entry structure, default filter, optional parameter, and the soft-delete context. This is complete for a simple listing tool with 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?

Although the schema provides no description for include_consumed, the tool description explicitly defines its meaning and effect, compensating fully for the schema 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 clearly states the tool lists frozen recipes, with a specific resource and action. It also distinguishes itself from sibling tools by focusing on frozen entries and the include_consumed option.

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 explicitly explains the default behavior (only active entries, count > 0) and how to see history via include_consumed=true. It also notes the soft-delete mechanism, which is essential for correct 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?

No annotations are provided, so the description carries the full burden. It implies a read-only listing operation with 'all' indicating a complete result, but it does not disclose ordering, return format, or any potential limits. This is minimal but adequate for a simple list tool.

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 sentence that is front-loaded with the action and resource. No filler or redundant wording.

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 lack of parameters and output schema, the description is sufficient for a basic list operation. It does not describe the return format, but for a list of categories, the expected output is likely an array of strings or objects, which is inferable from the context of the recipe application.

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 has zero parameters, so there is nothing for the description to add. The baseline for 0 params is 4, and the description correctly does not invent any parameter details.

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 action ('List') and the resource ('main-ingredient categories'), which is specific and distinguishable from sibling tools like list_recipes or list_courses. The scope is unambiguous.

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 context is clear: it's the tool for listing main-ingredient categories, as opposed to other list_* tools. There are no explicit exclusions or alternative mentions, but the purpose is so specific that an agent can infer when to use it.

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 only says 'List saved menus' without disclosing any behavioral traits such as read-only nature, pagination, return format, or potential side effects. It implies a read operation but doesn't state it, leaving the agent to assume safety. Minimal 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?

The description is a single, short sentence with no wasted words. It is perfectly concise and front-loaded with the action. For a zero-parameter list tool, this is appropriately sized.

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 simplicity (no parameters, no output schema), the description is minimally adequate. It tells the agent what the tool does. However, it could be improved by clarifying what a 'menu' is, or by noting that it returns a list of all saved menus without filtering. Still, for a straightforward list operation, it is not critically incomplete.

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 has zero parameters, so the description doesn't need to explain parameter semantics. The schema coverage is 100% (trivially, since there are no parameters), and the baseline for zero-param tools is 4. The description adds no parameter-specific info, but none is needed.

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 the verb 'List' and the resource 'saved menus' clearly, so the agent knows what it does. However, it doesn't distinguish it from sibling list tools like list_recipes or list_courses, relying on the resource name to differentiate. It's clear but not explicitly distinct.

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 vs alternatives. There is no mention of context, prerequisites, or exclusions. The agent must infer that this is the tool for listing menus, but the description provides no explicit 'when to use' or 'when not to use' information.

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. It states only that it lists events, without explicitly mentioning that it is read-only or has no side effects. While a list operation is inherently non-destructive, the description does not disclose this behavioral trait.

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, focused sentence that conveys the purpose and even previews the entry structure. There is no unnecessary verbiage or ambiguity.

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-all tool with no parameters and no output schema, the description is complete. It specifies the resource ('planner events') and provides a sample entry format, which is sufficient for an agent to understand what the tool returns.

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 has zero parameters, so the schema coverage is trivially high. The description correctly adds no parameter details, and the baseline for zero parameters is 4, which 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's function: 'List all planner (calendar) events.' It uses a specific verb ('List') and a distinct resource ('planner events'), and it is easily distinguishable from sibling tools like list_recipes or get_planner_week.

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 this tool is for retrieving all planner events without filtering, but it does not explicitly contrast it with alternatives like get_planner_week or find_planned_dates. Usage is self-evident for a simple list-all operation, but explicit guidance on when to use this versus other tools is missing.

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 and the description does not disclose any behavioral traits such as read-only nature, rate limits, or potential side effects. The verb 'list' implies non-destructive behavior, but it is not explicitly stated.

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, compact sentence that conveys the essential information: the action, the subject, and the cap limit. No unnecessary words or 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 simple list operation with no parameters and no output schema, the description fully covers what the tool does, including the scope and the entry cap. Nothing else is needed 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 tool has no parameters, so schema coverage is 100%. Per the baseline rule, a score of 3 is appropriate; the description adds no additional parameter meaning because none exist.

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 'List' and a clear resource 'the user's recipe book' with explicit scope (own + saved + queued + friend recipes). This distinguishes it from sibling list tools like list_courses and list_cuisines.

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 is provided on when to use this tool versus alternatives. The description does not mention conditions or alternatives, leaving the agent to infer usage from the resource name alone.

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 provided, the description carries the full burden of behavioral disclosure. It only states that it lists tags, but says nothing about return format, ordering, pagination, authentication, or any side effects. For a read-only operation this is minimal but not misleading; however, it lacks depth.

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 concise sentence with no filler. It is front-loaded and efficient, earning a high score for conciseness even though it is brief.

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 (no params, no output schema), the description is adequate but minimal. It doesn't explain what the returned tags look like or any filtering/sorting, which could be useful context. However, for a trivial 'list all' operation, the lack of detail is not severely detrimental, but it could be more 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 tool has zero parameters and the schema coverage is 100% (empty schema). Per the rubric, a zero-parameter tool gets a baseline of 4 since there is nothing for the description to clarify. The description adds no parameter information, but none is needed.

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 'List all tags' clearly states the verb (List) and resource (tags), making the purpose unambiguous. It is not a tautology and differentiates from sibling tools that operate on other resources like recipes or courses, though it doesn't explicitly name 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?

There is no guidance on when to use this tool versus alternatives. While the sibling list tools are for different resources, the description provides no explicit context, prerequisites, or exclusions. The usage is implied by the resource name but not elaborated.

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 present, so the description carries the full burden. 'Move' clearly implies a mutation, but it does not disclose side effects such as whether the event is removed from its previous location, whether conflicts at the target are possible, or what the response contains.

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, two sentences, and free of unnecessary detail. It communicates the essential purpose and scope without 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?

With no output schema and a relatively simple operation, the description covers the main purpose. However, it omits guidance on how this differs from reorder_planner_events and does not resolve the 'and/or' ambiguity versus the required date and section parameters.

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 0%, but parameter names are relatively self-explanatory (event_id, date, section). The description adds that date and section are the target values, but it does not explain that both are required despite 'and/or', nor does it clarify the meaning of section beyond the enum.

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 action ('Move'), the target resource ('an existing planner event'), and the specific change ('to a different date and/or section'). It also distinguishes from related tools by noting it works for recipe, note, and ingredient events.

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 purpose is implied well enough, but there is no explicit guidance on when to choose this tool over siblings like reorder_planner_events or update_planner_entry_text. It does not mention alternatives or exclusion cases.

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 full responsibility for behavioral disclosure. It discloses that reordering is meaningful only when events share date+section, but does not describe what happens otherwise (e.g., behavior, side effects, whether it's a permanent mutation, or any permission requirements). For a mutation tool with no annotation coverage, this is a significant gap.

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-loaded with the purpose, and every sentence adds value. It is concise and well-structured.

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 basic input requirement and a key constraint, but lacks details on the effect of the reorder (e.g., what happens to events not in the list, whether the order is absolute or relative, or what the response indicates). Given the simplicity of the schema and lack of output schema, it is somewhat complete but leaves important behavior unspecified.

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 0%, so the description must compensate. It adds that event_ids should be passed in desired order and belong to the same date+section, providing context beyond the bare integer array. However, it does not elaborate on the interpretation of the order (e.g., whether the first element becomes the first in the section) or whether the list must include all events in the section, leaving some ambiguity.

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 'Reorder' and the resource 'events within a section', and specifies that event_ids should be passed in desired order. It is unambiguous about the action and scope, but does not explicitly differentiate from sibling tools like move_planner_event, so it lacks explicit sibling differentiation.

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 a constraint that all events should belong to the same date+section for meaningful reordering, implying the tool is for reordering multiple events within a section. However, it does not explicitly state when to use this tool over alternatives like move_planner_event or provide exclusions, so guidance is only implied.

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 of behavioral disclosure. It only states the action without mentioning side effects, permissions, reversibility, or impact on other data. This is insufficient for a mutation tool.

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 concise sentence that is front-loaded with the primary action. It is appropriately sized for the operation, though it lacks critical details that would be covered under other dimensions.

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 tool with two required parameters, no output schema, and no annotations, the description is incomplete. It does not explain the event_id, the effect on the planner event, or any constraints on servings. An agent would need to look elsewhere for essential 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?

Schema description coverage is 0%, and the description does not explain either parameter. It mentions 'servings count' but not the event_id or constraints on servings. The description adds no meaning beyond the schema, leaving the agent without guidance on what these parameters represent.

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 ('Set') and resource ('servings count on a recipe planner event'), which clearly identifies the tool's function. It does not explicitly mention sibling tools, but the uniqueness of the action (setting servings) distinguishes it from other planner 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 on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. The agent must infer usage from the tool name and schema.

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?

Despite lacking annotations, the description exposes a key field-name quirk: it uses 'description' on the wire while entries are created with 'title'. This is valuable behavioral transparency beyond the basic action.

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?

Very concise: one clear sentence plus a focused note. No redundant wording, and the core 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 simple update operation, the description covers the essential behavior and the important field-name quirk, though it omits details about return values or potential errors. Still, the tool is simple enough that the description is 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 has no parameter descriptions, so the description must compensate. It partially does by indicating 'text' and the field-name note, but it does not explicitly explain that 'id' is the entry identifier or that 'description' carries the new text.

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 the action (update text) and the target (note or ingredient planner entry), distinguishing it from related tools like add_planner_note or update_planner_options.

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 this tool (to change text of an existing note or ingredient entry), though it does not explicitly mention when not to use it or name 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?

No annotations are present, so the description carries the full burden. It states that preferences are updated, but it does not disclose side effects, whether the update is a partial merge or full replacement, authentication requirements, or error 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 brief, front-loaded with the core purpose, and provides only essential examples and guidance. No filler 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?

It gives enough to start using the tool, but important practical details are missing: how preferences are applied (merge vs replace), whether nested keys are required, and what response or errors to expect. The 'Rarely needed' note adds some context but not full operational clarity.

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 itself provides no descriptions, but the description compensates with concrete allowed keys, value types, and Rails-style nested key examples like user[time_zone] and calendar_settings[show_calories]. It does not enumerate every possible option, but the 'etc.' is acceptable given the arbitrary object shape.

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 the action ('Update') and the resource ('planner display/behaviour preferences'), with concrete examples such as time_zone, planner_start_day, and calendar_settings.show_calories. It is distinct from other planner-related sibling tools, which target entries, events, or servings rather than preferences.

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 some usage context by saying 'Rarely needed' and showing the nested-key format, but it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions or edge cases.

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 behavioral disclosure burden. It does disclose important partial-update semantics and the ingredient removal convention, which goes beyond the raw schema. However, it doesn't mention side effects, required permissions, response behavior, or validation constraints.

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 two sentences that each add direct value. It avoids repetition and boilerplate, making it easy for an agent to parse quickly.

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 28 parameters, no annotations, and no output schema, the description is too thin to be complete. It omits guidance for most parameters, return values, error conditions, and operational context, leaving substantial gaps for an agent deciding how to 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 description coverage is only 18%, so the description must compensate for the large number of undocumented parameters. It only explains ingredient removal, while most other fields (nutrition values, timings, flags, associations) receive no semantic guidance beyond their names. This is insufficient for a 28-parameter tool.

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 ('Update an existing recipe') and clearly signals that this is a mutation of an existing entity, which distinguishes it from create_recipe and delete_recipe. It doesn't explicitly name a sibling alternative, but the meaning is unambiguous.

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, actionable guidance: pass only changed fields, and use {id, _destroy: true} to remove ingredients. It doesn't explicitly state when not to use this tool or point to alternatives, but the intended usage is clear.

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