Plate Artists

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful scope information by enumerating the outputs produced, but says nothing about how results are expressed (units, rounding, per-item breakdown) — appropriate for a 3 given the annotation coverage.

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, and the output list is placed after the trigger (guest count) where it belongs. It is dense but readable; a slightly crisper split of what-in vs what-out would earn a 5.

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 the necessary work of enumerating what is returned: item quantities and a board size. That is nearly complete for a small 3-parameter read-only calculator, though units and whether quantities are totals vs per-guest remain unstated.

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

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

Schema description coverage is 100%, and the schema even explains the occasion enum values and the guests/vegetarians bounds. The description adds no parameter-level meaning beyond that, so the baseline 3 applies. The mention of 'jars' and specific food categories hints at output content rather than input 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?

The description names a concrete calculation input (guest count) and concrete outputs (quantities of cheese, cured meat, crackers, fruit, nuts, jars, plus board size), which is far more specific than the tool name alone. It does not explicitly distinguish itself from adjacent calculators like party_food_calculator or ham_calculator, so it stops short of a 5.

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 when-to-use guidance, no exclusions, and no mention of the sibling calculators that could plausibly be chosen instead (party_food_calculator, ham_calculator, prime_rib_calculator). The agent must infer from the noun 'charcuterie board' that this is the right tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is settled. The description adds value beyond that by disclosing the return shape (titles, summaries, URLs) in the absence of an output schema, though it says nothing about result ordering or total counts.

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?

Front-loaded with the verb and resource, then the topic list, then the return shape, then the no-query behavior — a sensible order. The topic enumeration ('plating technique, garnishes, sauces, plate types, knife skills...') is long and partly redundant with the schema's example values, but it does convey scope.

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 only two optional parameters, no nested objects and rich annotations, the description covers nearly everything an agent needs to call it and interpret results. The notable omission is the default result count of 5, which lives only in the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks — that omitting the query returns every guide, which tells the agent the parameter is genuinely optional and what the empty case does. The limit parameter is left entirely to the schema.

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

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

States a specific verb (find) and resource (plating guides, board guides, holiday hubs, free tools) and enumerates covered topics, which makes it distinguishable from the calculator/recipe siblings. It does not explicitly contrast with search_recipes or get_recipe, so an agent must infer that this searches editorial guides rather than recipes.

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 clear usage context: use it for topic-based discovery of guides and tools, and it explains the no-query fallback ('lists every guide'), which is a real usage decision point. It names no alternatives or exclusions, so there is nothing steering the agent away from a wrong sibling choice.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the full shape of the returned payload, which matters because no output schema exists. It does not mention error behavior for a missing or out-of-range id, which keeps it from a 5.

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 sentence, front-loaded with the verb+resource and key, followed by a dense but scannable inventory of return fields. Nothing is redundant, though the colon-delimited list runs long and could have been trimmed of lower-value items like the page URL.

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

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

For a simple single-parameter read tool with strong annotations, the description covers the one thing structured data does not: what comes back. With no output schema, the content enumeration is exactly the right compensation. Missing only failure-mode context for an invalid id.

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

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

Schema coverage is 100% and the single 'id' parameter is already documented with type, range and provenance ('Recipe id from search_recipes'). The description adds only the phrase 'by id' and spends its text on return contents, so this is the expected baseline rather than added semantic depth.

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 resource and the retrieval key ('the full recipe by id') and then enumerates exactly what the payload contains (times, servings, ingredients, method, plating, food-safety, FAQ, URL). That is enough to distinguish it from search_recipes and random_recipe, though it never says so 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?

There is no when-to-use or when-not-to-use guidance and no sibling is named as an alternative. The only workflow hint ('Recipe id from search_recipes') lives in the schema, not the description, so an agent must infer that this tool follows a search rather than replacing 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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds that results come from USDA FSIS and include cooking/reheating time and safe temperature, which is real added context. It says nothing about how quantity scales with the appetite parameter or how the label/cut constraint manifests (error vs. adjusted result).

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?

Front-loaded with the outcome, then a compact glossary of label values and a one-clause caveat. Fragment style is dense but readable; no sentence is wasted, though the label glossary could be formatted more scannably.

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

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

No output schema exists, so the description correctly states what comes back: per-person quantity, cooking/reheating time, and safe temperature. For a 5-parameter calculator the main remaining gap is the unexplained appetite and cut semantics and how an unsupported label/cut pair is handled.

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?

With only 40% schema coverage, the description does heavy lifting by defining all four 'label' enum values (cooked/cbe/fresh/country) and flagging that cut availability varies by label. It leaves 'cut' (spiral/whole/half/boneless) and 'appetite' (dinner/leftovers) undefined, relying on intuition.

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

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

The opening sentence names a specific verb+resource: per-person ham purchase quantity plus USDA FSIS cooking/reheating time and safe temperature. It's clearly distinct in resource from siblings like turkey_calculator and prime_rib_calculator, though it never names an alternative 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 (meal planning for a ham) with a useful constraint caveat, 'Not every label has every cut,' which warns about invalid combinations. There is no explicit when-to-use vs. another calculator, and no guidance on when to pick this over party_food_calculator.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety bar is low. The description still adds value by disclosing the response units (inches and millimetres) and the empty-argument enumeration behavior, which annotations do not convey. It does not describe the shape of a single-cut response versus the full list, a minor remaining 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?

Two short sentences with zero filler. The core purpose and vocabulary come first, and the fallback rule is placed where it is needed, after the definition of the resource.

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 single optional-string, read-only lookup with no output schema, the description covers purpose, units, accepted vocabulary, and default behavior. Nothing an agent needs in order to call it correctly 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 coverage is 100% and the schema already supplies examples like "brunoise" and "allumette", so baseline is 3. The description goes beyond it by making the parameter's optionality meaningful — omission triggers a full listing — which the schema does not state.

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 (classic knife cut dimensions) and the exact fields returned (size and method, in inches and millimetres). It enumerates concrete example cuts and states the no-argument fallback behavior, so an agent can distinguish this lookup from any of the calculator/recipe siblings without opening the schema.

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

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

It explicitly states the conditional usage: supply a cut to get that cut, omit it to list every cut with its size. That resolves the only real invocation decision for a one-parameter tool. It stops short of naming alternatives or exclusions, but no sibling tool overlaps this scope.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and idempotence need no restating. The description adds that the values are catalog-derived and exact-match, but says nothing about the shape of the return (no output schema), whether cuisines and categories are returned as separate lists, or how complete the vocabulary is.

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 short sentence with no filler, and the subject (cuisines and categories) is front-loaded. The phrasing is a noun fragment rather than a statement of what the call does, which costs a little clarity but wastes no words.

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

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

For a zero-parameter, read-only lookup the description covers scope adequately, but with no output schema the agent gets no information on the return structure it must parse (e.g., two keyed arrays versus a flat list). One clause on the response shape would make this 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 takes zero parameters, so baseline is 4; the schema is empty and there is nothing for the description to clarify. The description's only semantic addition is that returned values are exact-match filters, which is relevant to how the output is consumed rather than how the call is made.

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 fragment 'The cuisines and categories in the recipe catalog' makes the resource concrete and distinguishes it from siblings like search_recipes and get_recipe by implying a lookup of filter vocabulary. It lacks an explicit verb ('list'/'return'), so the agent must infer the action from the tool name rather than the description.

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?

'to use as exact filter values' signals the downstream purpose — feeding exact-match values into a search — but never names search_recipes or states when not to call this tool. Usage is implied rather than routed; an agent could reasonably guess it's a prerequisite for filtered searches, but it isn't told so explicitly.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile needs no restating. Beyond that the description reveals almost nothing: it doesn't state the output shape (a shopping quantity list?), units, assumptions per guest, default behaviors when foods is omitted, or why hours is capped at 12. For a 5-parameter computation tool with no output schema, that leaves the agent guessing at results.

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 compact sentence with no filler, front-loaded with the core question. The awkward list ('appetizer pieces, then the mains, sides, salads, bread and desserts you pick, and drinks') is slightly convoluted but each phrase carries menu-scope 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?

This is a multi-parameter calculation tool with 5 params, 60% schema coverage, no output schema, and a hidden enum of 34 dish values. The description should convey what gets returned (quantities per dish), units, and the style semantics; it conveys none of that.

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 60%, and the description adds genuine meaning only for hours ('for drinks' - clarifying it feeds drink quantities, matching the schema's 'default 3'). It also signals the dietary categories via the food list, but adds nothing about style's three enum values, what omitting foods or drinks does, or how the maxItems caps matter. Baseline 3 given partial 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 implies a quantity estimator for party food and drink and enumerates categories (appetizers, mains, sides, salads, bread, desserts, drinks), but the verb is nominal: 'How much food and drink to buy' never states that the tool computes quantities from guests/style/hours. Siblings like turkey_calculator and ham_calculator are clearly per-dish calculators, so an agent can infer this is the whole-menu aggregate, but the description doesn't say that 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?

No when-to-use guidance and no routing to or away from siblings. It doesn't say whether this replaces per-item calculators like turkey_calculator or prime_rib_calculator, or how 'style' should be chosen. Usage is only implied by the description's menu framing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behaviour, so the safety profile is covered. The description usefully adds one non-obvious behavioural trait — the zero-argument call enumerates the colour families and plates, effectively acting as a discovery call — but says nothing about the shape or volume of the pairing results.

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 compact sentence covering both directions plus the empty-call escape hatch, front-loaded with the core value proposition. The semicolon-chained phrasing is slightly dense but every clause carries 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?

A low-complexity lookup tool with two enum parameters, no output schema, and full annotation coverage — the description covers both query modes and the discovery mode. Missing only the behaviour when both parameters are given, which is a minor gap at this complexity level.

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%, but both parameters are closed enums whose values are self-explanatory (plate names, colour families). The description adds real meaning by mapping each parameter to a use case and clarifying that food_color means the food's *dominant* colour. It does not clarify optionality or the combined-parameter case.

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, dual-direction resource: given a food's dominant colour it says which plate flatters or kills the dish, and given a plate it says which foods suit it. No sibling tool (recipes, calculators) does anything similar, so the agent can route here unambiguously.

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

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

Explicitly tells the agent to "call with neither to see the colour families and plates," which is the critical guidance for a tool whose parameters are both optional. It also implies two usage modes (food-colour-first vs plate-first). It stops short of saying what happens when both parameters are supplied at once.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing that the tool computes several derived values (weight, time, pull temp, rest) rather than a single number, though it says nothing about units or output formatting.

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?

Front-loaded and tight: the outputs are listed first and the two cooking methods come last. The phrase 'and the rest' is vague and the sentence is fragmentary rather than clearly structured, which costs a point.

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 six-parameter tool with only a third of parameters described and no output schema, the description leaves gaps: bone-in vs boneless sizing implications and the effect of leftovers on quantity are unaddressed. It is adequate to know what the tool does but not complete enough to use every option confidently.

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 33%, so the description should carry more weight than it does. It touches guest count, doneness, and cooking method implicitly, but says nothing about bone-in vs boneless, appetite, or leftovers, which are the parameters most in need of added meaning.

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 (prime rib / standing rib roast) and enumerates the concrete outputs: how much to buy, roasting time, pull temperature, and rest duration. It is unmistakable against siblings like turkey_calculator or ham_calculator, which handle different proteins.

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 only implied: an agent can infer this is for planning a prime rib roast for a guest count. There is no explicit when-to-use/when-not framing and no pointer to alternatives such as party_food_calculator or thanksgiving_timeline for broader meal planning.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and idempotentHint=false, so safety and repeat-call behavior are covered structurally. The description reinforces non-determinism by saying "one random" recipe and notes it returns a full recipe rather than a summary. It does not say what happens when the filters match nothing, which is the main remaining behavioral unknown.

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 compact sentences: the capability and its optional filters come first, the usage trigger second. Nothing is redundant and nothing obstructs the core statement.

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-required-parameter, no-output-schema tool this is close to adequate: the agent knows it gets one full recipe back. It falls short on edge behavior (no match for a filter) and on where cuisine/category values come from, which matters because those are free-form strings here.

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 carries the burden, and it only says the three params limit the result by "cuisine, category or vegetarian" without explaining that they are optional-and-narrowing (schema shows no required), or what values are legal. With a sibling list_recipe_filters existing and a 60-char string constraint, the description should point at the valid value space and does not.

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?

"One random full recipe" gives a concrete verb-and-resource (returns a single complete recipe, chosen at random) plus the three filter axes. "Full" usefully distinguishes it from a list-style search, though no sibling tool (search_recipes, get_recipe) is named for contrast.

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 trigger phrase "For 'what should I cook tonight?' questions" tells the agent the intent this tool serves, which is real guidance. However, it never states when to prefer search_recipes or get_recipe instead, nor any exclusion, so selection between random_recipe and its siblings still requires 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: it returns short cards with ids and URLs rather than full recipes, which is critical since there is no output schema. It stops short of mentioning the result cap or how matching ranks, keeping it at a 4.

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

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

Three short sentences, no filler. Scope comes first, the return shape second, and the routing instructions last, which is the right order for an agent scanning for a search entry point.

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 six optional parameters and no output schema, the description carries the burden well by describing the returned card shape and id/URL handoff to get_recipe. Nothing an agent needs to call this correctly 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 coverage is 100%, so the baseline is 3. The description earns extra by clarifying that query matches words in the dish name or keywords (broader than the schema's examples suggest) and that cuisine/category are exact-match values requiring a lookup via list_recipe_filters.

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 (search) and resource (Plate Artists recipe catalog), then enumerates the filter dimensions: dish name/keywords, cuisine, category, vegetarian, total time. It also explicitly distinguishes itself from get_recipe and list_recipe_filters, so an agent can route without opening a schema.

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

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

Gives explicit next-step routing: call get_recipe for the full recipe, and call list_recipe_filters for the exact cuisine and category values. This is a rare case of naming both the downstream tool and the prerequisite lookup tool, which fully covers the when-to-use question.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, closed-world), so the description's real contribution is provenance and output behavior: turkey times sourced from USDA FSIS and dish times from each recipe, plus the fact that it detects dishes that don't fit the ovens and supplies fixes. That is meaningful context beyond the annotations, though it says nothing about output format or size.

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?

It is a single long sentence with the core purpose front-loaded and each clause adding a distinct output element, so nothing is wasted. The run-on structure makes it slightly harder to scan than a short bulleted breakdown would be.

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 needs to tell the agent what comes back, and it does: a dated prep schedule, turkey timing, oven assignments, and conflict fixes. Combined with a fully documented optional-only schema and read-only annotations, the definition is nearly complete, missing only a note on result size or format.

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

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

Schema coverage is 100% and every parameter is documented with defaults and enum meanings, so the schema carries the burden. The description adds almost nothing parameter-specific beyond 'Every setting is optional', leaving it at the baseline for a fully documented schema.

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

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

The description names a specific artifact (a Thanksgiving cooking schedule worked back from dinner time) and enumerates what it contains: day-by-day prep, turkey in/out times, per-oven dish assignment, and overflow dishes with fixes. That level of detail separates it cleanly from siblings like turkey_calculator, which handle only a slice of the same problem.

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 by the scenario (planning a Thanksgiving cook) and 'Every setting is optional' signals it can be called with defaults, but there is no explicit when-to-use vs. when-to-pick-turkey_calculator guidance and no stated exclusions. An agent must infer the boundary from the purpose statement 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds value the annotations cannot: it discloses the substantive outputs the agent will receive, including USDA roasting guidance at a specific temperature and both thawing methods, which is important since no output schema exists.

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 compact sentence with zero filler, and the primary output (turkey size) is front-loaded ahead of the secondary timings. It reads as a noun-phrase list rather than a complete sentence, which is slightly less self-explanatory but costs no tokens.

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 correctly carries the return-value burden by naming all four computed results. For a read-only, idempotent calculator with fully documented parameters and no side effects, nothing critical is missing, though it could note that results assume standard USDA guidance.

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

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

Schema description coverage is 100%, with enums and even a default ('Default whole') documented inline, so the schema does the heavy lifting. The description only echoes 'guest count' and adds no interpretation of how 'stuffed', 'kind', or 'appetite' change the computed result beyond what the schema already states.

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 enumerates exactly what the tool computes: turkey size for a guest count, USDA roasting time at 325°F, fridge and cold-water thawing times, and done temperature. That is specific and unambiguous, though it never distinguishes itself from siblings like ham_calculator or prime_rib_calculator, relying on the name alone to convey the protein.

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 'for a guest count' implies the planning scenario, so usage is inferable. But there is no explicit when-to-use statement, no mention of the stuffing/appetite options as decision drivers, and no routing to alternatives such as prime_rib_calculator or thanksgiving_timeline for related planning tasks.

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