ReceiptCal

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

Annotations already declare destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description's 'without changing ReceiptCal data' usefully reinforces the non-destructive profile, but adds nothing about whether cancellation is reversible, what state the staged action ends in, or authorization needs.

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

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

A single front-loaded sentence with no waste. It is efficient and readable, though its brevity leaves the gaps noted in other dimensions unaddressed.

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 embedded in a prepare/confirm/cancel lifecycle, the description omits how the action_id is sourced, what 'staged' means, and how this relates to confirm_action. With a 1-param schema and annotations covering safety, the remaining burden falls on the description, which does not carry it.

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?

One parameter at 0% schema description coverage, and the description never mentions action_id — not its format, nor where the agent obtains a staged action's id. The schema only supplies maxLength/minLength constraints, so the description fails to compensate for the coverage gap.

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

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

States a specific verb ('Cancel') and resource ('staged ReceiptCal action') and adds a scope clarification ('without changing ReceiptCal data'). This distinguishes it from the many prepare_* siblings, though it never names confirm_action, the closest lifecycle neighbor.

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. Given the deliberate prepare_*/confirm_action pattern running through the sibling list, the description should say this aborts a staged action instead of confirming it, but offers nothing about that 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the important gate that execution must follow explicit user approval in a separate message, which is genuinely new behavioral context; it does not say whether the action_id is consumed or expires after execution.

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 with the operation front-loaded and the precondition trailing it; every clause earns its place and there is no boilerplate.

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 destructive, non-idempotent execution tool with no output schema and no parameter documentation, the description covers the confirmation gate but omits what happens on success or failure, whether the prepared action is consumed, and whether action_id has a validity window. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description has to carry the load. It implicitly maps 'one prepared ... write' to action_id and 'explicitly approved' to user_confirmed, which is useful, but it adds no format, lifetime, or error semantics for action_id beyond the schema's min/max length.

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 (Execute) and a tightly scoped resource (one prepared ReceiptCal write), which cleanly separates it from the many prepare_* siblings that only stage an action and from cancel_action. An agent can tell what this does and what it does not do 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?

Gives an explicit precondition for use: only after the user has approved the displayed preview in a new message. It does not name cancel_action as the alternative when approval is withheld, nor state what to do if the user edits the preview instead, so the when-not path is left implicit.

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 behavior, so the baseline is covered. The description adds domain-specific context that the output is a handoff URL and explicitly rules out checkout/order placement, which is valuable beyond the annotations, though it omits validation failure behavior or expected URL contents.

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

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

Two tight sentences front-load the core action and then immediately clarify the safety boundary. Every phrase earns its place with no repetition or filler.

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

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

For a simple two-parameter URL builder with rich annotations and no output schema, the description is adequate to understand the operation. However, with 0% schema description coverage it should explain associate_tag and quantity semantics, and it does not, leaving a meaningful gap.

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 carry parameter meaning, but it only vaguely references ASINs. It does not explain quantity bounds, the maximum of 25 items, the ASIN pattern, or what associate_tag is for, leaving key inputs undocumented.

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

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

States a specific verb and resource (create and validate an Amazon cart handoff URL from ASINs) and scopes it by clarifying it does not open checkout or place an order. It distinguishes the operation type from true cart-creation or checkout siblings, but never names a specific sibling to route against.

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

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

The description provides a useful when-not by clarifying no checkout or order is placed, which implies this is the URL-only path. However, it gives no explicit guidance on when to choose this over siblings like prepare_create_recipe_cart or resolve_amazon_products, leaving the agent to infer.

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 closed-world, so the safety profile is covered. The description still adds real value by disclosing exactly what data is bundled and that safety constraints are surfaced read-only. It omits any note on document size, auth requirements, or how the artifact is delivered.

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 with zero filler. The verb and output format come first and the enumerated data scope follows, so the most decision-relevant information is front-loaded.

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

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

With no output schema, the description carries the burden of describing the result, and it does state the format (ReceiptCal Markdown) and the contents. It stops short of saying whether the document is returned inline or as a downloadable artifact, which is the one remaining gap for a zero-parameter export 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate — baseline 4 applies. The description correctly avoids inventing arguments that do not 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 ("Render") and enumerates the exact resources included (food preferences, pantry, learned food memories, safety constraints) plus the output format (ReceiptCal Markdown). It is clearly distinguishable from most siblings, though it never names its inverse sibling prepare_import_memory_document, which is the most likely confusion point.

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 explicit when-to-use guidance, no conditions or prerequisites, and no named alternative. An agent must infer from the word "portable" that this is for extracting a user's data outside the system, and must infer on its own that prepare_import_memory_document is the counterpart.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral detail – that the output partitions features into MCP-backed, device-only, browser-only, and auth-helper-only – but says nothing about freshness or response shape.

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 that states the resource and its two-part scope with no filler. Every clause 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?

With no output schema, the description must carry the return-value burden, and it does sketch the categories returned. It stops short of explaining what distinguishes an MCP-backed feature from a device-only one or what the entries look like, which is a minor gap for a zero-param read-only 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema's empty object with additionalProperties=false is consistent with the description's no-argument framing.

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 resource (MCP-backed features vs device-only/browser-only/auth-helper-only features), so the agent knows exactly what comes back. No sibling tool overlaps this discovery function, so no differentiation is needed, but the description doesn't explicitly scope it against anything.

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 infers it should call this when it needs to know which capabilities are server-backed versus client-side. There is no explicit when-to-use statement, no prerequisites, and no exclusions.

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 the safety profile is fully covered. The description adds only that the returned list is the latest one and may be in draft or approved state, which is modest added context but reveals nothing about emptiness, ordering, or shape.

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 key qualifier ('latest') appears before the state qualifiers. Nothing could be cut without losing 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?

With no output schema, the description should at least sketch what comes back; 'draft or approved grocery list' hints at state but leaves the returned structure, item fields, and behavior on an empty list unstated. Adequate for a trivial zero-param read, but thin.

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 there is nothing for the description to disambiguate and the baseline for a no-param tool applies.

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

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

States a specific verb (read) and resource (grocery list) with a scope qualifier (latest draft or approved). It is distinguishable from prepare_create_grocery_list and prepare_approve_grocery_list, though it never names those siblings to sharpen the distinction.

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

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

The phrase 'latest draft or approved' implies this is the retrieval path for the active list, but there is no explicit when-to-use guidance, no mention of when to prefer prepare_create_grocery_list or prepare_approve_grocery_list, and no stated prerequisites.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that meal intentions are included in the result; it says nothing about behavior when no active plan exists. Some added value, but thin against the annotation baseline.

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, which is correctly sized for a zero-parameter read tool. It is efficient rather than padded, though correspondingly minimal.

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-argument, no-output-schema read whose annotations already cover safety and idempotency, the description covers the essentials. The only gap is unstated behavior when no active meal plan exists, which is minor given the tool's simplicity.

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

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

The tool takes zero parameters and the schema is a bare empty object, so there is nothing for the description to disambiguate. Baseline 4 applies: no parameter semantics are needed or 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?

"Read the active meal plan and its meal intentions" states a specific verb (read) and resource (the active meal plan, plus its intentions), which distinguishes it from generic list_meals/list_v2_meals. It stops short of naming sibling tools like list_meal_intentions or prepare_create_meal_plan, so sibling differentiation is only implied.

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 offers no when-to-use or when-not-to-use guidance. With siblings such as list_meal_intentions, get_current_grocery_list, and prepare_create_meal_plan available, an agent gets no explicit signal for choosing this tool over those. Only the name implies the retrieval 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful qualifier 'private', hinting at authorization scoping, but leaves opaque what 'support-link state' means and how missing/expired reports behave. That is modest added value over the annotations.

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

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

One short sentence, front-loaded with the verb and the two things it returns, with no filler.

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

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

There is no output schema, so the description should carry the return contract; it names 'delivery status' and 'support-link state' but does not describe the shape or fields of either, nor error behavior for unknown report IDs. For a one-parameter read tool this is the minimum viable 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?

The schema has one report_id with a UUID pattern but 0% description coverage; the description only implies that the ID selects 'one ReceiptCal customer report'. With a single self-evident required parameter this is adequate, not enriching.

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 ('Read') and a specific resource ('delivery status and support-link state of one ReceiptCal customer report'). It is clearly distinguishable from the create/retry customer-report siblings, though it never names them 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 guidance on when to use this versus prepare_retry_customer_report or prepare_create_customer_report_draft, and no noted exclusions or preconditions. Usage is only implied by the words 'read ... status'.

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 content-level value by enumerating which preference categories are returned, which matters given there is no output schema. No contradiction with the annotations.

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

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

A single front-loaded sentence with no filler. The eight-item category list is slightly dense but each item conveys what the caller will receive.

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 parameters, no output schema, and annotations covering the safety profile, the description's enumeration of returned categories is close to sufficient. What is missing is only the routing context relative to get_profile and the update sibling.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to explain beyond confirming the read is unfiltered and household-scoped.

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 (Read) and resource (personalized food profile) and enumerates the profile categories it returns. It is distinguishable from prepare_update_food_profile by the read verb, but it never names siblings or clarifies the boundary with get_profile.

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 the read path for personalization data, but there is no explicit when-to-use, when-not-to-use, or routing against get_profile / get_personalized_recommendations which sit right beside it in the sibling list.

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 the safety profile is fully covered. The description adds only a hint about output content ('history coverage', 'meal assessments'), which is mild extra context rather than substantive behavioral disclosure such as what happens with sparse data.

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 and resource, with zero filler or repetition. It is appropriately sized for a single-parameter read tool, though the jargon could be tightened.

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 rich annotations covering safety but no output schema, the description should explain what the overview returns; it gestures at 'history coverage and bounded meal assessments' without defining them. Adequate for calling the tool, incomplete for interpreting 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 coverage is 0%, but the single parameter's bounds (1-90) are already encoded in the schema's minimum/maximum, and the description merely restates that range ('one to 90 days'). No default, format, or interpretation guidance is added beyond the schema, so it neither compensates nor misleads.

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 verb 'Read' and resource 'quality overview' are present, but qualifiers like 'evidence-aware' and 'bounded meal assessments' are jargon that don't pin down what the overview actually contains. It also does nothing to distinguish itself from neighbors like get_product_quality or get_nutrition_summary.

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 prerequisites, and no named alternative among the ~70 siblings (e.g. get_product_quality, get_nutrition_summary) that would tell an agent which quality/summary tool to pick. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that results are organized as 'lots' with 'expiration estimates', which is modest extra context about shape rather than 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?

A single short sentence with the resource and the returned content front-loaded. There is no filler, hedging, or restatement of the title.

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

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

With no output schema, the description carries the burden of conveying return values; 'lots and expiration estimates' is a useful but thin sketch. It says nothing about ordering, pagination, or whether expired lots are included, which an agent likely needs.

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 there is no parameter semantics burden to carry; the baseline for a 0-param tool applies. Nothing in the description misrepresents the empty schema.

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

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

The description gives a specific verb and resource ('List current pantry lots and expiration estimates'), which is clearly distinguishable from generic inventory verbs. It does not, however, differentiate itself from the close sibling get_use_soon_pantry, leaving the agent to infer the scope difference.

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 prerequisites, and no mention of alternatives such as get_use_soon_pantry or get_current_grocery_list. The agent must infer the trigger condition from the noun 'pantry inventory' 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds value by enumerating the four state components returned (meal request, recipe, grocery list, commerce), but says nothing about freshness/staleness or behavior when nothing has been saved yet.

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 the verb and the aggregate scope up front and no filler. Every element 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?

With no parameters, no output schema and annotations covering safety, the description carries the return-value burden itself and does so by listing the four data groups returned. It is nearly complete, missing only edge-case behavior (e.g., response when no meal request exists).

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

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

The tool takes zero parameters, so per the rubric this baseline is 4. The description correctly implies no inputs are needed by describing a pure 'latest' lookup.

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 ('Read') and a concretely scoped resource ('most recent saved meal request, recipe, grocery list, and commerce state'). The word 'most recent' implicitly separates it from the sibling get_meal_request, but the description never names that sibling, so the differentiation is left to inference.

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

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

Usage is implied: fetch this when you need the current aggregate state rather than a specific request. There is no explicit when-to-use/when-not clause and no reference to the sibling get_meal_request, which is the obvious alternative for retrieving a non-latest request.

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 the safety profile is fully covered elsewhere. The description adds no behavioral context beyond that — nothing about not-found handling, authorization, or return shape — so it contributes nothing an agent does not already have.

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 wasted words. It is efficient, though arguably under-specified rather than deliberately tight given the gaps in usage and behavioral guidance.

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 with a full annotation safety profile, the definition is minimally adequate. With no output schema, the description could reasonably say what a meal request contains or what happens when the id is not found, and it does neither.

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 is one parameter with 0% schema description coverage, so the description must compensate. 'By identifier' at least confirms the parameter's role as the lookup key, but adds no format or sourcing detail beyond the UUID pattern already expressed structurally in the schema.

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

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

States a specific verb (Read), resource (meal request), and scope (one, by identifier), which distinguishes it from the sibling get_latest_meal_request and the prepare_* variants. It stops short of explicitly naming those alternatives, so it is clear but not sibling-routing.

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 condition, no exclusions, and no alternative named. An agent cannot tell from the description when to call this versus get_latest_meal_request or get_current_meal_plan beyond the bare word 'identifier'.

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 annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false, so the safety and mutability profile is covered. The description adds the phrase 'evidence-aware,' which hints at a calculation methodology but does not explain data sources, freshness, or failure modes, so additional behavioral value is limited.

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 no filler. Every word contributes to identifying the calculation and its supported periods.

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 two-parameter read-only tool, the description gives the core purpose and the period options. However, it omits any explanation of the timezone offset parameter and leaves 'evidence-aware' undefined, so it is only minimally sufficient.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It lists the three period enum values, but those are already present in the schema and it says nothing about the optional timezone_offset_minutes parameter or its effect on the calculation. This leaves a meaningful input undocumented.

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 (Calculate), resource (calorie and macro totals), and scope (today, last seven days, previous calendar week). It is clear enough for an agent to understand the tool without opening the schema, but it does not explicitly differentiate itself from any sibling tools.

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

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

The description implies that the tool should be used to obtain nutrition summaries over the listed periods, but it does not state when to use it versus alternatives, nor does it provide any exclusions or prerequisites. Usage is only inferable from the purpose.

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 covered. The description adds real value by disclosing the content of the read (progress, remaining fields, next prompt), which matters because no output schema exists to convey return shape.

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 that names the action first and the returned artifacts second, with no filler or restatement of the title.

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

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

For a zero-param read tool with full annotation coverage, the essentials are present, but the description never relates onboarding state to the larger flow or to prepare_advance_onboarding, and "food-personalization onboarding" is left undefined against general onboarding. Adequate, but with a clear gap in workflow 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?

Zero input parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description neither adds nor loses anything here.

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 ("Read") and resource ("food-personalization onboarding progress") and enumerates what comes back: remaining fields and the next assistant prompt. It does not, however, name or contrast itself with the obvious sibling prepare_advance_onboarding, so an agent must infer the read/write split from the naming convention.

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 stated when-to-use, no precondition, and no reference to the sibling that mutates onboarding state (prepare_advance_onboarding). The read-only framing is implied by "Read" but nothing routes the agent to this tool over the 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?

Annotations declare readOnlyHint=false, which is surprising for a "get" tool; the description resolves that by disclosing that ReceiptCal records a private analytics event, explaining the write side effect. That is meaningful behavior beyond the structured hints, though return format and result limits beyond "up to 20" are unstated.

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

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

Two tight sentences with the core purpose front-loaded and no filler. It earns its length, though the side-effect sentence could be slightly more explicit about 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?

For a tool with 0% parameter coverage and no output schema, the description should explain what servings/max_minutes do and roughly what the response contains. It covers the ranking signals but omits any parameter guidance, leaving the agent to guess on inputs.

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 there are two parameters (servings, max_minutes) with no description and no constraints explained. The description never mentions either parameter, so it fails to compensate for the schema gap at a point where it must.

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

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

States a specific verb and resource ("Get up to 20 personalized recommendations") and enumerates the ranking signals (pantry, safety constraints, food profile, learned memories), so the agent knows exactly what comes back. It does not, however, distinguish itself from the sibling get_recommendations, leaving the "personalized" vs plain recommendation distinction to inference.

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 prerequisites, and no mention of the near-identical sibling get_recommendations that an agent would need to disambiguate between. The description assumes the caller already knows the 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?

Annotations are present but the description adds meaningful context they don't convey: the assessment is 'bounded', it hits an external source (Open Food Facts), and it 'updates private rate-limit and cache state'. That last point justifies the otherwise surprising readOnlyHint=false for a 'get' tool. It stops short of describing failure or rate-limit-exceeded 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?

Two tight sentences, front-loading the core action before the side-effect note. No filler; every clause carries information. It could arguably merge into one sentence, but the split is defensible.

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 should ideally sketch what a 'quality assessment' returns (score, grade, flags), which it does not. It does cover purpose, non-persistence, and side-effects, so it is adequate but leaves the return shape undocumented.

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 burden shifts to the description, which only says 'one barcode' — conveying single (not batch) resolution but no format, length, or source-encoding guidance. The machine-readable pattern and length bounds live in the schema, so the description adds marginal value.

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

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

States a specific verb (resolve) plus resource (one barcode) and names the data source and scope ('bounded Open Food Facts quality assessment'). This differentiates it from the sibling resolve_barcode and the broader get_food_quality_overview, though it never names those siblings explicitly.

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

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

The clause 'without logging a meal' implies a usage boundary against prepare_log_barcode / logging tools, which is helpful routing context. However, no alternative tool is named and no when-to-use condition is stated explicitly, so usage 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that (nothing about defaults when the profile is unset, freshness, or auth). Its field list is effectively return-value description, which is useful but not a 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?

A single front-loaded sentence with the verb first and the returned contents following; no filler, no restatement of the title.

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

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

With no output schema, the field enumeration is the only description of what comes back and it is reasonably specific. It stops short of covering edge behavior (e.g., what is returned before a profile exists), but for a zero-parameter read with rich annotations that is a minor gap.

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 there is nothing for the description to disambiguate; baseline 4 applies. The description does not invent parameter-like options, which is correct for a no-arg getter.

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

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

Specific verb ('Read') plus resource ('household profile') and an enumeration of the fields returned (household size, food preferences, allergies, targets, planning defaults), which lets an agent predict the payload. However, it does not differentiate itself from the very similar sibling get_food_profile, so an agent cannot tell from the description alone which of the two to call.

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

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

There is no when-to-use guidance at all: no mention of when this is preferable to get_food_profile or get_onboarding_state, and no note that it is the read counterpart to prepare_update_profile. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The line 'Does not grant permission' adds a genuine boundary beyond annotations, but the description says nothing about what the 'sharing disclosure' contains, any auth/scoping requirements, or failure 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?

Two tight sentences with the read scope front-loaded and the permission caveat placed last where it acts as a guardrail. No filler, though the brevity leaves content gaps rather than earning full marks.

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?

There is no output schema, so the description should describe the return shape (boolean contribution state plus disclosure contents), which it only gestures at. Combined with the undocumented parameter, this is minimally viable but not 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% for the single meal_request_id parameter, and the description supplies no meaning for it at all – not even that it identifies the meal request whose contribution state is read. With one undocumented parameter the description fails to compensate 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 verb 'Read' plus the object 'recipe contribution status' and 'sharing disclosure' gives a workable purpose, but 'contribution' and 'sharing disclosure' overlap heavily with the sibling get_recipe_sharing, and the description never distinguishes the two. An agent must guess from the name alone which read tool to pick.

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 grant permission' implicitly tells the agent this is not the prepare_contribute_recipe action path, which is useful routing. However there is no explicit when-to-use guidance and no reference to the closely-named siblings it must be chosen over.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful rollout/version gating context ('Available with the 6.0 library rollout') but says nothing about return format or pagination.

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, front-loaded sentences with no waste. The rollout note is slightly cryptic but occupies little space.

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-arg, read-only tool with no output schema, the description conveys enough: it reads the sharing disclosure and current permission, and annotations carry the safety profile. Return-value detail is thin but the title and description together make the payload reasonably predictable.

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?

Zero parameters, so there is no parameter semantics to document; the 100% coverage is trivially satisfied. Baseline 4 applies for a no-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?

States a specific verb (Read) and resource (sharing disclosure and current permission), which clearly distinguishes it from the write-oriented sibling prepare_set_recipe_sharing. It doesn't name the sibling explicitly, but 'before changing sharing' implies the pairing.

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?

'before changing sharing' gives a clear workflow trigger for when to call this tool, effectively positioning it as a prerequisite read ahead of the mutation. No explicit when-not guidance or named alternative, so it stops short of a 5.

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

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

The description usefully discloses a non-obvious side effect ('the backend records that recommendations were shown'), which is consistent with readOnlyHint=false and non-idempotent annotations and explains why this 'get' is not pure. It stops there, saying nothing about rate limits, cost, or whether repeated calls change output.

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, front-loaded sentences with no filler; the core purpose and count limit land first. It is arguably too terse for the missing information, but there is no wasted text to trim.

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 fully undocumented parameters, no output schema, and a competing sibling, the description leaves too much unsaid. An agent can invoke it, but not confidently choose it or set servings/max_minutes meaningfully.

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 never mentions the two parameters. The bounds on servings (1-12) and max_minutes (5-240) are documented only in the schema, and there is no explanation of what either controls or whether they are optional.

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

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

The description states a specific verb and resource (get meal recommendations) plus two useful scoping facts: 'up to three' and 'pantry-aware'. It does not, however, distinguish this from the sibling get_personalized_recommendations, leaving the agent to guess which recommender applies.

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 statement of when to call this versus alternatives, no prerequisites, and no exclusions. With a directly competing sibling (get_personalized_recommendations) in the toolset, the absence of routing guidance is a real gap.

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 (readOnly, idempotent, non-destructive, closed-world), so the description is freed to add real value: it enumerates what gets checked and defensively states 'Never returns an access token,' a security-relevant disclosure not derivable from annotations. It stops short of describing the response shape or failure modes.

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 tight sentence that front-loads the verb and the three checks, with the token disclaimer appended efficiently. No redundant or filler text.

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-param diagnostic tool with no output schema, the description covers what is checked and the key guarantee (no token returned). Slightly more on the returned status/error distinction would make it fully self-sufficient, but nothing critical is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics to document; the schema is trivially complete. Baseline 4 applies with nothing further the description could add.

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 (Check) and three concrete resources: API reachability, local authentication state, and account-connection instructions. No sibling tool performs a connection/diagnostic check, so an agent can distinguish this immediately from the prepare_* and get_* siblings.

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 (verify connectivity/auth before attempting ReceiptCal-backed operations) but never stated as an explicit when-to-use condition, and no alternatives or exclusions are given. Adequate minimum-viable guidance given that no sibling overlaps.

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 real context by saying the read is 'minimum' (bounded/least-privilege) and spans four specific domains, but it says nothing about permissions, latency, or how the returned slice varies by task.

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 tightly-worded sentence with no filler, and the scoping qualifier ('minimum') is front-loaded. It is efficient, though it is arguably too terse given the unexplained enum and absent output contract.

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?

There is no output schema, so the description carries the burden of describing what comes back — and it does not, beyond naming four domains. Combined with an entirely undocumented task enum, an agent cannot know what it will actually receive or which task value fits its situation.

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 enum values are listed but never explained. The description partially compensates by implying the returned context is task-conditional ('minimum ... needed for one supported task'), which tells the agent that different enum values yield different context slices, but it does not define what 'recommendation', 'voice', 'pantry', or 'portion' actually return.

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

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

The description gives a specific verb ('read') and a compound resource ('safety, profile, memory, and pantry context'), which conveys that this is an aggregating context fetch rather than a single-domain getter. However, 'one supported task' is never disambiguated and the tool is not distinguished from siblings like get_profile, list_safety_constraints, or list_memories, which retrieve the same underlying domains.

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 explicit when-to-use guidance, no statement of when to prefer this bundle over calling get_profile/list_memories/list_safety_constraints directly, and no prerequisites. 'Needed for one supported task' hints at a workflow but never names the conditions that select 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?

Annotations already declare the full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description is not burdened with stating safety. It adds one useful behavioral trait—that results are prioritized by expiration reasoning—but does not explain ordering, thresholds, or what 'prioritized' concretely means.

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 wasted words. It is appropriately terse for a zero-parameter read tool, though it is very short and leaves some questions unaddressed.

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-param, fully-annotated read tool this is near-adequate, but with no output schema the description could reasonably say more about what is returned and how 'priority' is determined. It stops at the minimum needed to identify 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?

The tool takes zero parameters, which is the baseline-4 case per the rubric. There are no parameter semantics to document, so no gap 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?

States a specific verb (Read) and resource (pantry items) with a clear scope modifier (prioritized for near-term use by expiration reasoning). It is distinguishable in concept from get_inventory, though it does not explicitly name or contrast with that sibling.

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

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

Usage is implied by the name and phrasing ('use-soon', 'near-term use'), so an agent can infer it is for surfacing expiring items. However, there is no explicit when-to-use guidance, no mention of when to prefer get_inventory instead, and no exclusions.

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 the safety profile is covered. The description adds two pieces of value beyond that: the 50-message cap and the security-relevant warning that message content is untrusted data, which matters for prompt-injection handling.

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, zero waste, with the operational scope ('up to 50') front-loaded and the trust caveat appended where it belongs.

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 parameterless list tool with no output schema, the description conveys the return scope and the trust caveat adequately. It stops short of noting whether more than 50 messages can be retrieved or how to page past the cap.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless call and adds no misleading parameter detail.

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 ('Read') and resource ('saved ReceiptCal assistant messages') with an explicit scope ('up to 50'). It is distinguishable from the only chat-related sibling (prepare_send_chat_message), though it does not name that sibling to reinforce the 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?

No guidance on when to use this tool versus alternatives, no preconditions, and no exclusions. The agent must infer that this is the read side of the chat feature purely from the verb.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the set of statuses returned and says nothing about ordering, pagination, scope, or empty-result behavior, so it contributes little beyond structured data.

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. It is as short as a list tool description can be while still naming the resource and its statuses.

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 tool with no output schema, the description is adequate to identify the call but does not describe what a meal intention record contains or how results are ordered or bounded. The missing return-shape detail matters because no output schema exists to fill the gap.

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

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

The tool takes zero parameters, so the schema carries no semantics to compensate for; baseline 4 applies. The description cannot add parameter meaning because there are no parameters.

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 resource (meal intentions), and enumerates the statuses returned (planned, prepared, consumed). It does not distinguish itself from closely related siblings such as list_meals, list_v2_meals, or get_current_meal_plan, so an agent still has to guess which listing tool to pick.

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 prerequisite, and no named alternative among the many listing siblings. Usage can only be inferred from the name, which is exactly the ambiguity that matters here given list_meals and get_current_meal_plan exist.

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 read-only, idempotent, and non-destructive. Beyond them the description adds two pieces of context the schema cannot convey: that the caller must be authenticated, and that receipt/merchant text is untrusted data (a prompt-injection trust boundary). It still omits ordering, pagination, and result 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?

Two compact sentences with no filler, and the core purpose is front-loaded ahead of the safety note. Slightly terse on detail, but nothing is wasted.

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

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

For a simple read-only list tool whose annotations already carry the safety profile, and with no output schema to explain, the description is broadly sufficient. It is missing ordering/pagination expectations and any differentiation from 'list_v2_meals', which an agent in this large sibling set would benefit from.

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 single 'since' parameter is undocumented in the schema. The phrase 'optionally from a timestamp' partially compensates by implying 'since' is a timestamp lower bound and is optional, but format/units are never stated.

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

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

The description names a specific verb and resource ('List ... ReceiptCal meal records') and adds scope ('optionally from a timestamp'), so an agent knows exactly what it returns. It does not, however, distinguish this from the sibling 'list_v2_meals', leaving ambiguity about which listing tool to pick.

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 alternative sibling is named. With 'list_v2_meals' in the same namespace, the absence of routing guidance is a real gap.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the meaningful detail that the data is "account-scoped" and "learned," but says nothing about volume, pagination, or freshness of the memories.

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 the verb first and no filler. Every word contributes to scoping the returned data.

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 carries the burden of conveying the return shape; it lists content categories but omits list mechanics such as ordering, count, or whether results are bounded. For a no-arg read tool this is adequate but not 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 there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level explanation is needed or 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?

States a specific verb ("Read") and a well-scoped resource ("ReceiptCal's account-scoped learned preferences, habits, household facts, portions, cuisines, and dislikes"), so an agent knows exactly what data it returns. It does not, however, distinguish itself from adjacent siblings such as prepare_observe_memory, prepare_edit_memory, or export_memory_document.

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 explicit when-to-use or when-not-to-use statement and no named alternative, but the enumeration of content categories (preferences, habits, household facts, portions, cuisines, dislikes) implicitly tells the agent what kind of question this tool answers versus get_food_profile or list_safety_constraints.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the pagination/boundedness trait, which is useful, but says nothing about default page size, ordering, or empty-result 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?

A single front-loaded sentence with no redundant phrasing; the scope qualifier is placed before the payload description. It is efficient, though extremely terse for a tool with two undocumented parameters.

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 two-parameter read tool with full annotation coverage and no output schema, the description is minimally adequate: it names the returned entity and its sub-content. It falls short on paging semantics (defaults, page size, end-of-list signposting), which is the main thing an agent needs 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 of explaining limit and offset. 'Bounded page' vaguely gestures at pagination but gives no default, no page-size guidance, and no hint that offset is the paging cursor, leaving both parameters semantically undocumented.

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 (Read) and resource (saved recipe cards and their ingredient choices) with a scope qualifier (bounded page). An agent can tell what it returns, but nothing in the text distinguishes it from adjacent list/recipe tools such as get_recipe_contribution or list_meals.

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, no prerequisites, and no alternatives named among the many sibling list/get tools. The only usage signal is 'bounded page', which hints at paging but not when to prefer 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description still adds real context by specifying that only 'confirmed' constraints are returned and that the source is the personalized profile, but says nothing about ordering, completeness, or what an empty result means.

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 front-loaded sentence with the verb first and no filler; every clause (the four constraint categories, 'confirmed', 'personalized profile') 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?

With no input params and a low-complexity read, the enumerated categories effectively stand in for the return shape even though no output schema exists. Minor residual gap: it does not say whether results include severity, source, or how exclusions differ structurally from allergies.

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

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

The tool takes zero parameters, so the schema baseline is a 4 and there is nothing for the description to disambiguate or compensate for.

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 concrete verb ('Read') plus an enumerated resource set (allergies, intolerances, dietary restrictions, excluded foods) with the source ('personalized profile'). This clearly separates it from the write-side siblings prepare_upsert_safety_constraint and prepare_delete_safety_constraint, though it never names them or get_food_profile 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 only implied: an agent can infer this is the lookup to run before proposing meals or logging intake. There is no explicit statement of when to call it, nor any pointer to the sibling that should be used instead for editing constraints.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the returned field categories but omits pagination behavior, filtering semantics, and any auth or rate-limit context.

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 no redundant or filler content. Every phrase contributes to identifying the resource and returned fields.

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

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

The description explains the kind of detailed records returned, which helps because there is no output schema. However, it leaves the "since" filter and pagination behavior unexplained, so it is only minimally complete for invocation.

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

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

Schema description coverage is 0%, and the only parameter, "since", is not mentioned or explained in the description. With one optional undocumented parameter, the description does not compensate 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 uses a specific verb ("List") and resource ("detailed meal records") and enumerates the kinds of fields returned, so the agent can tell it is a detailed read operation. It does not explicitly contrast with the sibling list_meals tool, so sibling differentiation is inferred rather than stated.

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 explicit guidance on when to use this tool versus alternatives such as list_meals, nor any condition for using it. The agent must infer usage from the word "detailed" and the field list.

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=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is partly covered by structured data. The description adds that the turn may update the food profile and confirmed allergy constraints, which is useful context beyond the annotations, but it never explains the staging/confirmation workflow implied by the 'prepare' prefix or the consequence of repeated non-idempotent calls.

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 efficient sentence that is front-loaded with the core action. Nothing is wasted, though the brevity comes at the cost of the missing usage and parameter 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 non-read-only, non-idempotent staging tool with no output schema and one fully undocumented parameter, the description is too thin. It omits the confirmation step, expected return, and the semantics of the transcript, leaving real gaps for an agent to fill.

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 single required parameter 'transcript' is not mentioned in the description at all. Saying 'text onboarding turn' only loosely implies a text input, adding little meaning beyond the parameter name.

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

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

The description states a specific verb and resource ('stage one text onboarding turn') and clarifies what the turn can do (update food profile and confirmed allergy constraints). It is understandable on its own, though it does not distinguish itself from siblings like prepare_update_food_profile or prepare_upsert_safety_constraint that appear to touch the same 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?

There is no guidance on when to use this tool versus the many sibling prepare_* tools, nor any prerequisite or sequencing information (e.g., whether it must follow get_onboarding_state). The agent must infer usage entirely.

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 the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the bar is lower. The description usefully adds that the upload is 'staged' and that 'Analysis records are stored by ReceiptCal,' plus the 'allowed directory' constraint. It does not explain what staging entails (e.g., a follow-up confirm_action) or any validation/failure 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?

Two short sentences, zero filler, with the core action front-loaded before the storage note. Could be tightened slightly but is efficient.

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

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

For a single-parameter staging tool with no output schema and annotations already covering safety, this is nearly adequate: formats, directory restriction and record storage are covered. The notable gap is any hint about the staging/confirmation workflow that the 'prepare_*' naming implies.

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 0% schema description coverage, the description must carry the burden: it names accepted image formats and the 'allowed directory' constraint, which is real meaning beyond the bare 'string' schema. However it never explains what an allowed directory is, path syntax, or what happens if the path is rejected, so it only partially compensates.

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+resource: 'Stage an upload of a local ... receipt image.' The format list (PNG, JPEG, HEIC, WebP) confirms it is the image variant, implicitly distinguishing it from the sibling prepare_analyze_receipt_text, though that sibling is never named.

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: the agent infers it should use this tool when it has an image file and the text variant when it has text. There is no explicit when-to-use/when-not statement and no reference to the prepare_analyze_receipt_text alternative in the sibling set.

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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows it is a non-destructive, non-idempotent write. The description adds genuinely new context beyond that: analysis records are persisted by ReceiptCal and no meal is logged, which is exactly the kind of side-effect disclosure annotations cannot convey. It omits the confirm/cancel staging flow, keeping 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?

Two short sentences, zero waste, with the core action front-loaded and the side-effect disclaimer immediately after. Nothing is padded or repeated from the title.

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

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

For a low-complexity one-parameter tool with no output schema, the description is nearly adequate, and it correctly discloses the persistence side effect. The significant omission is that a 'prepare_' tool in this family is expected to be paired with confirm_action/cancel_action before taking effect — an agent would not learn that 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% for the single 'text' parameter, so the description carries the burden. It does clarify that the input is receipt text rather than free text, but adds no format, encoding, or length expectations despite the 100000-char cap in the schema. Marginal value over the schema.

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

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

The description states a specific verb and resource: 'Stage an upload of receipt text for deterministic ReceiptCal nutrition analysis.' This clearly separates it from the text-vs-file distinction implied by the sibling 'prepare_analyze_receipt_file', though the sibling is never named explicitly.

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

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

Usage is implied by the 'stage an upload' phrasing, suggesting a preliminary step, but the description never states when to prefer this over prepare_analyze_receipt_file, nor that it must be followed by confirm_action. The 'no meal is logged' note clarifies a boundary but is framed as a side-effect caveat rather than routing guidance.

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

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

Annotations already declare the mutation profile (readOnly=false, destructive=false, idempotent=false). The description adds genuinely useful context by disclosing that this is a staging step and that approval does not submit an order. It stops short of explaining the confirm/cancel flow or what happens if the draft is rejected.

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, action stated first and the key constraint (no order submission) front-loaded with zero padding.

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-parameter staging tool with no output schema this is adequate but not complete: the description never links to confirm_action/cancel_action, which is the whole point of the prepare_* pattern, and the parameter's expected state is only weakly conveyed.

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 carry the parameter burden, but it only implies the id refers to a 'draft' list. The UUID format and the requirement that the list be in draft state are not spelled out anywhere the agent can see without parsing the pattern.

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

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

States a specific verb and resource: staging the approval of a draft grocery list. The 'draft' qualifier and 'stage' scoping distinguish it from prepare_create_grocery_list and from any true submission action, though siblings like confirm_action are never named.

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 prepare_* naming and the clause 'Approval does not submit an order,' which sets a boundary. However, the description never says when to call it versus alternatives, nor that a subsequent confirm_action (a sibling tool) is what actually executes the approval.

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 the safety profile: writable (readOnlyHint=false), non-destructive (destructiveHint=false), non-idempotent (idempotentHint=false), and closed-world. The description adds useful context that this is a staging action with a reward ledger side effect. However, it does not elaborate on non-idempotency, what staging entails, or what happens if the action is never confirmed.

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 no wasted words. The phrase 'bounded weekly reward ledger' is slightly jargon-heavy but still concise and informative.

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

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

Given the tool's complexity (a staging mutation with two parameters, no output schema, and 0% schema coverage), the description is too sparse. It omits critical details about the staging process, parameter selection, and the reward ledger's bounded nature, leaving significant gaps for an agent to infer.

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 only vaguely maps to the two parameters by mentioning 'a saved recipe meal or recipe card', but provides no details on format, constraints (minLength 8, maxLength 160), or how to choose between meal_id and recipe_card_id. The anyOf requirement is also unaddressed.

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 ('Stage confirming') and resource ('saved recipe meal or recipe card as home cooked') and mentions a side effect ('applying the bounded weekly reward ledger'). It is clear what the tool does, though it does not explicitly differentiate from siblings like prepare_consume_meal or prepare_log_meal_request_serving.

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 explicit guidance on when to use this tool versus alternatives. The word 'Stage' implies a preliminary step, but the description does not state that confirmation via confirm_action is required, nor does it contrast with other meal-logging siblings.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so the mutation/non-idempotent profile is covered. The word "Stage" hints at a deferred prepare→confirm workflow (confirm_action exists as a sibling), which is useful context beyond the annotations, but the description never explains what staging commits to or that a confirmation step may follow.

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; the action and target are stated up front. It is dense with vendor jargon ("stage", "meal intention") but not padded.

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

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

For a non-idempotent mutation with no output schema and no annotation detail on auth or side effects, the description omits what the agent needs: whether the intention must be pre-prepared, whether inventory/nutrition is deducted now or on confirmation, and what happens after staging. The staging flow is implied but never made explicit.

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 full burden, and it only gestures at both params conceptually ("servings", "meal intention"). It gives no units, no valid range for servings, and no hint about how to obtain meal_intention_id, so it under-compensates for the empty schema.

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

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

The description supplies a verb ("Stage logging") and resource ("consumed servings for a prepared meal intention"), so it is more than a tautology. However, "stage" is unexplained jargon and the definition draws no line between this tool and close siblings like prepare_record_portion or prepare_log_meal_request_serving, leaving the agent to guess which one applies.

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 statement, no prerequisites, and no named alternative among the many meal-intention and logging siblings. It states what happens but never when an agent should reach for this tool over prepare_record_portion or prepare_log_meal_request_serving.

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 write (readOnlyHint=false), idempotent, non-destructive, closed-world. The description adds real behavioral context beyond that: it is consent-gated, personal/imported recipes carry an attestation requirement, and 'privacy/safety review can keep content private' tells the agent the contribution is not guaranteed to publish. It does not say what the call returns or whether review is synchronous, so it is short of 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?

Three tight sentences, front-loaded with the action and immediately followed by the consent prerequisite, so the most important gating information is not buried. The closing privacy-review sentence is slightly soft in wording but does carry actionable meaning, so there is little waste.

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, consent-gated mutation tool with no output schema, the description covers the risky parts an agent needs: the disclosure/permission precondition, the attestation requirement, and the possibility that review keeps content private. The only notable gap is the unexplained meal_request_id and the absence of any indication of what the call produces (e.g., a pending contribution).

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 carry parameter meaning. It effectively explains the semantics behind origin ('personal/imported'), permission_attested ('affirm their right to share'), and consent_version ('disclosure and explicit permission'), but never addresses meal_request_id, which is a required parameter with a UUID pattern. Partial compensation for a full coverage gap lands at the minimum-viable baseline.

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+resource+scope: 'Offer one owned recipe for community reuse,' which is clearly distinct from sibling tools like get_recipe_contribution, prepare_withdraw_recipe_contribution, and prepare_set_recipe_sharing (a settings toggle). It does not explicitly name a sibling to differentiate against, but the 'one owned recipe' scope is specific enough for an agent to route correctly.

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

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

Gives a clear precondition chain: show the disclosure, obtain explicit permission, and for personal/imported origins require the user to affirm their right to share, with the explicit rule 'never infer this.' No alternative tools are named, so it stops short of a full when/when-not comparison, but the context for invoking it is unambiguous.

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 establish the mutation profile (readOnlyHint=false, non-idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful context beyond that: it is a 'staging' step rather than final delivery, targets a 'private' tracker, and explicitly notes that account identity and scan images are excluded (a privacy/data-handling 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?

Two tight sentences with no filler, and the core purpose plus the notable exclusion are front-loaded. Efficient and well-structured, though it is short relative to the complexity of the operation.

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 non-idempotent mutation with 6 undocumented parameters, no output schema, and multiple sibling report tools, the description is thin. It omits parameter details, the relationship to the draft/retry/status flow, and any note on retry behavior despite the non-idempotent annotation.

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% across 6 parameters, including two enum fields (category, context_type) and a nested 'diagnostics' object whose inner fields are entirely undocumented. The description adds nothing about parameter meaning, so it fails to compensate for the coverage gap.

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

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

States a clear verb ('stage') and resource (a high-priority ReceiptCal customer report) plus its destination (the private support tracker), so the operation itself is unambiguous. However, it does not distinguish this from the sibling 'prepare_create_customer_report_draft', which an agent could easily confuse with 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?

The description gives no explicit when-to-use guidance and never names the related siblings ('prepare_create_customer_report_draft', 'prepare_retry_customer_report', 'get_customer_report_status'). An agent gets no routing signal for choosing this over the draft or retry variants.

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 the operation as non-read-only, non-destructive, non-idempotent, and closed-world. The description adds important context: it stages a draft that is never submitted and warns against including secrets. It doesn't cover permissions, rate limits, or response behavior, but for a staging tool the added value is strong.

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 core purpose followed by a security warning and behavioral note. It is efficient, though the phrase 'private writing help' could be tightened for clarity.

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

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

For a simple two-parameter write tool with no output schema, the annotations cover safety and the description adds a privacy constraint and non-submission behavior. However, it completely omits parameter semantics, leaving an agent unsure how to populate 'category' and 'report_text' correctly.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. It never mentions the 'category' enum or what 'report_text' should contain, leaving the agent to infer their meaning entirely from the schema. This is a significant gap given the low 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 action ('Stage private writing help') and resource ('ReceiptCal issue report'), and clarifies it 'creates a draft and never submits it,' which distinguishes it from the sibling prepare_create_customer_report tool that presumably submits. The term 'private writing help' is slightly opaque but the surrounding context makes the purpose clear.

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

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

Usage is implied: this tool is for staging a draft, not submitting, and should exclude sensitive data. However, there is no explicit statement of when to use this versus alternatives like prepare_create_customer_report or prepare_retry_customer_report, nor any prerequisites or exclusions beyond the security warning.

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 declare readOnlyHint=false but destructiveHint=false, and the description usefully clarifies the write is only a draft that orders nothing, plus a pantry-exclusion side effect. It still omits repeat-call behavior even though idempotentHint=false implies duplication is possible, and no auth/permission context is given.

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

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

Two tight sentences with zero filler, front-loading the core action and ending on the constraint that most affects agent decisions. 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?

For a 5-parameter write tool with no output schema and zero schema documentation, the description gives an adequate mental model but leaves parameter-level semantics (retailer, quantity/unit handling, the 40-item cap) unexplained. Adequate, not 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% across 5 parameters, so the description carries the burden and only partially meets it. It gestures at items ('named groceries'), pantry exclusion (keep_even_if_in_pantry), and recipe-derived entries (meal_request_ids / use_latest_recipe), but retailer is never mentioned and no format or limit guidance is added.

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 (stage a draft) and resource (grocery list) plus its inputs (saved-recipe ingredients, named groceries) and its key filtering rule (omit what the pantry holds). The closing 'Nothing is ordered' cleanly separates it from order-placing siblings like prepare_create_recipe_cart and prepare_create_ingredient_cart.

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 'stage a draft / nothing is ordered' phrasing implies this is the pre-ordering step and hints at alternatives that actually order, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer that approval/ordering routes through prepare_approve_grocery_list.

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=false, idempotentHint=false and destructiveHint=false, so the write/not-destructive profile is covered. The description adds useful context beyond that — it is a staging handoff that persists a commerce session and leaves checkout to the user — but says nothing about auth requirements, rate limits, or what happens to prior session state.

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

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

Two tight sentences, front-loaded with the core action and followed by the scope boundary. No filler, though it is perhaps too terse given the complexity of the items array it accepts.

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 tool with no output schema and a nested parameter array at 0% schema coverage, the description omits return format (it only alludes to a 'cart URL'), what the saved commerce session means, and how the item objects should be shaped. Significant gaps remain 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?

Schema description coverage is 0% and the single 'items' parameter is a nested array with four sub-fields (ingredient, organic_only, quantity_hint, brand_preference) plus min/max item limits. The description never mentions any of this structure, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb and resource: staging ingredient requests into a retailer cart URL and saving the commerce session. The word 'ingredient' implicitly distinguishes it from the sibling prepare_create_recipe_cart, but it never names or contrasts that sibling 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 guidance, no prerequisites, and no routing to alternatives such as create_cart_url or prepare_create_recipe_cart. The only boundary offered is 'Checkout remains with the user,' which clarifies responsibility but not invocation conditions.

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 this is a non-read-only, non-idempotent, non-destructive, closed-world mutation. The description adds value by using 'stage', signalling a two-step prepare/confirm pattern rather than an immediate write. It stops short of stating what gets created, what happens if left unconfirmed, or whether repeated calls stack up duplicate intentions.

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 padded preamble, which is good. But it is compressed to the point of ambiguity: 'stage planning' and 'optional time' would each benefit from a clarifying clause, so brevity here costs clarity rather than earning 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 three-parameter mutation with no output schema and only default annotations, the description omits the key things an agent needs: where recipe_id comes from, that the staged action must be finalized with confirm_action, and what a successful stage returns. The scope note ('built-in') is helpful but insufficient.

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 carry the load. It explains 'serving count' and 'optional time', loosely covering servings and scheduled_for, but says nothing about recipe_id — where it comes from, its format, or that it must reference a built-in recipe. Constraints such as the 0.25–24 serving range and the 40-char time format are undocumented.

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 verb ('stage planning') and a resource ('built-in ReceiptCal recipe'), which is more than a restatement of the title. However, 'stage planning' is awkward phrasing that doesn't clearly map to the meal-intention concept in the tool name, and it doesn't distinguish this from siblings like prepare_create_meal_plan or prepare_prepare_meal.

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 word 'built-in' hints at a scope constraint (only catalog recipes, not user-created ones), which is the only usage signal present. There is no explicit when-to-use, no mention of the confirm_action follow-up needed to commit a staged action, and no comparison to competing siblings such as prepare_create_meal_plan.

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 write/idempotent/destructive flags. The word 'Stage' usefully implies this is a draft/pending operation presumably requiring a later confirm_action, and 'draft' signals the grocery list is not yet committed. Beyond that it does not say what gets created, whether it is reversible, or what confirmation step follows.

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, verb and resources stated up front. It is efficient, though arguably under-specified rather than maximally concise.

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 4 optional params, no output schema, and no annotations explaining the 'stage' lifecycle, the description leaves key questions open: what the staged plan contains, what happens after staging, and how the drafted grocery list relates to prepare_create_grocery_list. More context 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?

Schema description coverage is 0% across 4 parameters. The description only hints at 'days' (via 'one-to-seven-day'); servings, start_date, and max_minutes are undocumented in both schema and description, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Stage creating a ... meal plan and draft grocery list') with a clear scope ('one-to-seven-day'). However, it does not differentiate from siblings such as prepare_create_grocery_list, which also concerns a grocery list, leaving the boundary between the two unclear.

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 indication of when to use this tool versus alternatives (e.g. prepare_prepare_meal, prepare_create_grocery_list, get_current_meal_plan). The day range is a parameter constraint, not usage guidance.

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

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

Annotations already disclose that this is a non-read-only, non-idempotent, closed-world, non-destructive operation. The description adds that it stages a natural-language request and generates/saves a recipe and grocery list, but it does not clarify what 'stage' entails, side effects, or later retrieval 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 a single front-loaded sentence with no filler. Every clause contributes to the tool's purpose without redundancy.

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

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

For a one-parameter tool with no output schema and annotations covering the safety profile, the description states the action and saved outputs. It is nearly complete, though it could briefly clarify the staged request lifecycle or when to use it over sibling tools.

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 for the single 'message' parameter is 0%, so the schema provides no semantic description. The description compensates somewhat by saying the input is a natural-language meal request, but it adds no format, content, or example detail beyond that.

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 ('Stage') and resource ('natural-language meal request') and names the generated artifacts (recipe and grocery list). It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as prepare_create_meal_plan or prepare_create_grocery_list.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternatives. The description only implies that this tool is for staging a meal request, leaving the agent to infer whether to use it versus sibling creation tools.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows the safety profile. The description adds useful context beyond that - it saves a commerce session and deliberately does not complete checkout - but it omits whether the staged cart replaces a prior one, what happens if it is never confirmed, and what state it leaves behind.

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

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

Two tight sentences with the primary action front-loaded and the scope boundary second. Every sentence earns its place, though the jargon-heavy first sentence could be slightly clearer.

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 non-idempotent mutation with no output schema, the description should explain the two-phase prepare/confirm flow and give at least minimal parameter meaning. It covers the operation's intent and the checkout boundary but leaves the confirmation lifecycle and both parameters undocumented.

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 neither parameter is named. 'Resolving a ReceiptCal recipe' loosely implies recipe_id, but the servings parameter (with its 0.25-24 range) is entirely unaddressed, so the description does not compensate for the documentation 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 gives a specific verb and resource: staging the resolution of a ReceiptCal recipe into a retailer cart URL and saving the commerce session. It is clear what the tool does, but it never differentiates itself from close siblings like create_cart_url, prepare_create_ingredient_cart, or prepare_create_grocery_list, so an agent cannot tell them apart from the text alone.

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?

'Stage' hints that this is a preparatory step and 'Checkout remains with the user' sets a scope boundary, but there is no explicit when-to-use, no mention of the confirm_action/cancel_action follow-up that a 'prepare_' tool presumably requires, and no comparison to the alternative cart tools.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds useful scope ('permanent', 'server-side data'), but does not clarify the staging semantics — whether calling it deletes anything, how long the staged state persists, or whether it must be paired with confirm_action. The 'permanent deletion' wording sits in mild tension with destructiveHint=false, though 'Stage' keeps it from being an outright contradiction.

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

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

A single front-loaded sentence with no filler; the staging intent and the affected scope are stated immediately.

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 staging tool with no output schema, the description is usable but incomplete: it omits what 'staged' means operationally (confirmation requirement, cancellation, expiry, reversibility) — the most important context for a deletion-intent 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?

Zero parameters and 100% schema description coverage, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-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?

States a specific verb ('Stage') and resource ('permanent deletion of the authenticated ReceiptCal account and its server-side data'), so the agent knows exactly what is being prepared. It is clear but does not explicitly differentiate itself from the confirm_action/cancel_action workflow or from other prepare_* siblings.

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 word 'Stage' implies a two-phase flow, but the description never says when to call this versus alternatives, that a later confirmation is required to actually delete, or that the staged action can be cancelled. No prerequisites, exclusions, or alternative tools are named despite confirm_action/cancel_action being siblings.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description adds real context: the deletion is permanent and scoped to a single (already confirmed) constraint. It does not clarify the staging/confirmation lifecycle, and the 'permanently deleting' phrasing sits in mild tension with destructiveHint=false even though a prepare-step can legitimately be non-destructive.

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. Efficient, though the terse wording leaves the lifecycle implied rather than stated.

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 state-changing tool in an explicit prepare/confirm orchestration set (siblings confirm_action and cancel_action), omitting that this only stages an action and needs later confirmation leaves a material gap, especially with no output schema to reveal the returned handle or status.

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. 'One' signals the single safety_id and 'confirmed' hints at the confirm flag, but it adds no format, source, or lookup guidance (e.g. how to obtain the UUID) beyond the schema's own pattern and const constraints.

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

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

Names a specific verb (stage permanently deleting) and resource (food safety constraint from the personalized profile), so it is distinguishable from list_safety_constraints and prepare_upsert_safety_constraint. It stops short of explicitly naming those siblings, so a 4 rather than 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?

No when-to-use, when-not-to-use, or alternative is given. The 'prepare_' prefix implies a two-phase workflow, but the description never says a follow-up confirmation (confirm_action) is required, which is the single most useful usage fact here.

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=false, destructiveHint=false and idempotentHint=false; the word 'Stage' usefully signals a two-phase workflow rather than an immediate mutation. However, the description never explains what staging implies (deferred commit, confirm_action needed, that 'forget' only marks a memory for removal) and gives no repeat-call semantics despite idempotentHint=false.

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 front-loaded sentence with the action set enumerated; nothing wasted. Brevity is achieved at the cost of the missing workflow detail, but structurally it is efficient.

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

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

For a non-idempotent, non-read-only staging tool with 0% schema coverage and no output schema, the definition is too thin: it omits the confirm/cancel lifecycle, per-action parameter expectations, and what happens to the memory after each action.

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% across 3 parameters, so the description must carry the meaning and it does not. It names the action values but never explains memory_id, nor that 'statement' (1-240 chars) is presumably required for the 'edit' action and irrelevant for 'keep'/'forget'.

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 ('Stage') and resource ('learned ReceiptCal food memory') plus the three outcomes (edit/keep/forget), which distinguishes it from list_memories and prepare_observe_memory. The jargon 'ReceiptCal' slightly blurs what domain of memory is meant.

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 statement of when to pick this over prepare_observe_memory, list_memories, or export_memory_document, and no note of prerequisites. Critically, it never says the staged result needs confirm_action (or cancel_action) to take effect, even though both siblings exist.

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 write/non-destructive/non-idempotent, and the description adds genuinely useful behavior beyond them: it is merge-only, it updates the listed entities, omitted entries and safety constraints are left unchanged. It omits confirmation/auth requirements for the staged action, 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?

A single dense sentence with the core action front-loaded before the contrast clause; no filler. The colon-and-semicolon structure packs a lot in, though the length is near the point where it could be split for clarity.

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

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

For a one-parameter tool with no output schema and full annotation coverage, the description covers what changes and what is preserved. The main gap is not explaining the staged prepare→confirm flow or input constraints, but otherwise it is sufficient to invoke correctly.

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

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

One parameter with 0% schema description coverage, so the description carries the burden. It does tell the agent the 'markdown' input is a ReceiptCal portable memory document, which adds real meaning, but it omits format/size expectations (e.g. the 70000-char limit) required to call it correctly.

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

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

Specific verb ('Stage merge-only import') plus a concrete resource ('a ReceiptCal portable memory document'), and it enumerates scope (learned memories, food preferences, pantry amounts). It does not explicitly name a sibling to differentiate from (e.g. prepare_merge_food_preferences), but the scope statement is clear enough for an agent to 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?

Implies the use case (importing a portable memory document) and sketches the merge-only semantics, but gives no explicit when-to-use vs alternatives, no mention of the confirm_action staging step, and no conditions under which to prefer a sibling like prepare_merge_food_preferences.

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 cover the safety profile (non-destructive, non-idempotent, closed-world), and the description adds real value by disclosing that this is a staged rather than committed write plus the 1–100 item bound. It still omits what staging means operationally — whether it expires, how it interacts with confirm_action, and what happens on repeated staging of the same items.

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; the scope constraint and destination are stated immediately. It is efficient, though the extreme brevity is part of why the usage and parameter gaps exist.

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 staged-write tool with no output schema and only generic annotations, the description should explain the stage-then-confirm flow and the role of source/retailer/source_reference. As written it leaves an agent unsure how the staged inventory becomes real or how to attribute the intake.

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 is the only place parameter meaning can be added, and it only restates the item-count bound. The source enum (receipt/manual/barcode/commerce), retailer, and source_reference — plus the per-item fields like quantity_confidence and storage_location — are left entirely to the raw 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 ("Stage adding") and resource (one to 100 items to the ReceiptCal virtual pantry), which is enough to separate it from read tools like get_inventory. It does not differentiate itself from the closest sibling, prepare_reconcile_inventory, or from per-item logging tools such as prepare_log_recognized_food.

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 statement of when this tool applies versus alternatives (reconcile, log_barcode, log_recognized_food) and no mention that staging must be followed by confirm_action. The agent must infer the workflow from the shared "prepare_" prefix.

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 this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds genuinely useful context with 'Stage', implying a two-phase flow rather than immediate commit, but it never says how the staged entry is finalized (e.g. confirm_action) or what happens on re-staging.

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 tight sentence with the action front-loaded and no filler. It does lean on internal jargon ('ReceiptCal meal') that costs a little clarity for the space it saves.

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 tool with no output schema and no annotations explaining the staging lifecycle, the description should cover prerequisites, the confirm/cancel step, and the meaning of scan_id. It covers almost none of this, leaving an agent unsure how to complete the log.

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 only loosely names two of three parameters ('barcode', 'serving mass'); the required scan_id is never mentioned at all. No units, format, or range guidance is provided, so the description fails to compensate for the coverage gap.

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

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

States a specific action ('Stage logging') plus the resources involved (resolved product barcode and serving mass), which distinguishes it from resolve_barcode and the broader prepare_log_* siblings. The 'ReceiptCal meal' target is jargon but the core verb+resource 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 word 'resolved' implicitly signals the prerequisite that the barcode must already have been resolved (via resolve_barcode) before staging. However, it never states when to prefer this over prepare_log_recognized_food, prepare_log_meal_request_serving, or the other log-staging siblings, leaving the routing decision 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?

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds meaningful context with 'Stage', signalling the action is queued rather than immediately committed. However it omits what happens after staging, whether it requires a saved meal request to exist, and how to commit or discard 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?

A single, front-loaded sentence with no filler. Every word contributes to the action, source, and target.

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 one parameter and no output schema, the description is nearly sufficient, but for a staged mutation tool it should clarify the commit/discard mechanism and any precondition (an existing saved meal request). Those gaps leave an agent guessing about the follow-up step.

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

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

The single parameter has no schema description (0% coverage), but the phrase 'from a saved meal request' semantically maps to meal_request_id as the source identifier. That is modest added value over the bare UUID pattern; no format or lookup guidance is given.

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 action (stage logging one serving) with a named source (a saved meal request) and destination (a ReceiptCal meal), which is far better than a tautology. It does not, however, explicitly differentiate itself from close siblings like prepare_log_recognized_food, prepare_log_barcode, or prepare_record_portion.

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 explicit when-to-use guidance, no prerequisites, and no mention of the alternatives for logging a serving. The 'prepare'/'stage' phrasing implies a two-step flow, but the description never names confirm_action/cancel_action or tells the agent when this path is preferable.

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 'Stage' adds useful context beyond the annotations by implying this is a preparatory action rather than the final log, and 'grounded USDA nutrition' signals the nutrition source. It does not explain what staging means operationally, whether confirmation is required, or what side effects occur, so with annotations already covering the mutation/safety profile this is only moderate added value.

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

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

The description is two tight sentences with the core action front-loaded and no wasted language. The negative scope sentence earns its place by preventing the wrong image-analysis use case.

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 non-readonly staging tool with four parameters, no output schema, and 0% schema description coverage, the description is too thin. It omits the required scan_id semantics and does not explain the next step after staging, leaving the agent to infer important lifecycle and invocation details.

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 carry parameter meaning. It identifies food name, confidence, and serving mass, but leaves the required scan_id unexplained and does not mention constraints such as confidence minimum 0.35 or serving maximum 2000.

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

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

The description gives a specific verb ('Stage logging') and resource ('already recognized food name, confidence, and serving mass'), and explicitly excludes image analysis. It is clear enough to distinguish this from image-based recognition, though it does not name the sibling alternatives it differs from.

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 clearly frames the tool as intended for already-recognized food data and explicitly says it does not analyze an image, which provides a useful when-not boundary. However, it does not name the alternative analysis tool or explain the confirm/cancel lifecycle after staging.

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=false and destructiveHint=false, so the mutation profile is known. The word 'stage' adds real value by implying a prepare/confirm two-step flow rather than a direct commit, but the description never states whether a confirm_action follow-up is required or what happens to the staged data.

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 wasted words; the verb and target profile come first. Slightly under-specified rather than verbose, which is a content issue rather than a structure one.

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 tool with no output schema, the description covers the inputs and implies a staging flow, but omits the lifecycle (what confirms the merge), permission needs, and merge semantics (replace vs. append). Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does name all four conceptual inputs (allergies, dietary preferences, disliked ingredients, cuisines), which maps well to the four parameters, but adds no format, syntax, or validation guidance beyond the field names.

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 ('stage merging') and resource (allergies/dietary preferences/disliked ingredients/cuisines) into a named profile. It is clear what the tool does, but it does not differentiate itself from closely related siblings like prepare_update_food_profile or prepare_update_profile.

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 offers no when-to-use guidance or alternatives. It never explains the relationship to prepare_update_food_profile, nor whether this should be used for incremental 'newly stated' inputs versus a full profile update. Usage context is only faintly implied by 'newly stated'.

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

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

Annotations declare the mutation profile (readOnlyHint=false, non-idempotent, non-destructive), but the description adds genuine value by revealing 'Stage', implying a two-phase commit (likely requiring confirm_action), and 'bounded'. It still omits what confirm/cancel flow is needed and what happens to existing memories on merge.

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 tight sentence with the verb front-loaded and no redundant restatement of the title. It is efficient, though its brevity comes at the cost of the missing detail elsewhere.

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 non-idempotent mutation tool with 5 undocumented parameters, no output schema, and a two-phase 'prepare' pattern, the description is thin. It never explains the staging-to-confirm lifecycle or how it relates to list_memories and prepare_edit_memory.

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% for 5 parameters, so the schema carries none of the semantics. The description only vaguely gestures at 'bounded' (hinting at the 240-char statement limit) and 'food-related' (hinting at the type enum); key, source, contradicts, and the type/source enums are entirely unexplained.

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 action (stage recording or merging) on a specific resource (a bounded food-related memory observation), which is clearer than a tautology. However, it does not distinguish itself from close siblings like prepare_edit_memory or prepare_merge_food_preferences, especially given the word 'merging' overlaps with the latter.

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 offers no when-to-use guidance, no exclusions, and no named alternatives despite a crowded sibling set of memory and preference tools. An agent must guess whether this or prepare_edit_memory / prepare_merge_food_preferences is the right entry point.

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

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

Annotations already declare this non-readonly, non-idempotent and non-destructive, and the description adds the important fact that pantry inventory is debited. It still omits what 'staging' produces, whether the deduction is reversible, and why the non-idempotent hint matters (i.e., that repeated calls would deduct again).

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, front-loaded with the action before the side effect. Nothing is padded, though the phrasing 'Stage preparing a meal intention' is slightly awkward.

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 mutating, non-idempotent tool with no output schema and 0% documented parameters, the description leaves too much unstated: what the call returns, whether the intention's state changes, and how to recover from an accidental double deduction.

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% for two parameters. The description never explains meal_intention_id (a UUID referencing a planned intention) or what servings_prepared does, even though it implies ingredient scaling. With no schema text to lean on, the description should have carried this burden 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?

The description names a resource (a meal intention) and a concrete side effect (deducting recipe ingredients from virtual pantry inventory), which is more than a restatement of the name. However, the key verb 'stage' is left undefined, and with siblings like prepare_consume_meal and prepare_create_meal_intention in the same family, an agent cannot tell from the text when staging differs from consuming or creating.

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 and no alternative named. The closest sibling, prepare_consume_meal, is never referenced, so the agent must guess whether this precedes consumption or replaces 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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write-but-non-destructive profile is covered. The word 'Stage' adds real context (this is a two-phase pending change), but the description omits how the staged change is later confirmed or cancelled.

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 efficient sentence with the action and both modes front-loaded. It is dense but not padded, though the phrasing 'Stage confirming...' is slightly convoluted.

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 tool with no output schema and zero parameter documentation, the description covers the core action but leaves out the staging lifecycle (confirm/cancel), permission needs, and the meaning of the quantity constraint. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies 'present' (presence vs. absent) and 'quantity' ('optional corrected quantity'), which is meaningful, but 'inventory_id' gets no semantic explanation and the boolean's polarity is only implied.

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

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

The description names a specific verb ('stage') and resource ('inventory lot') with two clear modes: confirming presence with an optional corrected quantity, or marking absent. It is distinguishable from siblings like prepare_intake_inventory, though it does not explicitly contrast with them.

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, no exclusions, and no mention of the alternatives. Critically, it never explains that this 'stages' a change requiring confirm_action to commit, so an agent gets no routing or lifecycle 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds one piece of real behavioral value beyond that: the call updates a persistent 'learned portion profile', so the write is not confined to the observation itself. It still omits what the staging lifecycle does and what the write interacts with.

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 tight sentence with the staged-operation framing and the resource up front and no filler. It is efficient, though the terseness trades away structural cues (lifecycle, parameter roles) that would help an agent.

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 non-idempotent mutation with three parameters at 0% schema documentation and no output schema, the description is thin. It does not explain the staged/confirm lifecycle, does not document the source enum's meaning, and does not state the prerequisites or the effect on an existing portion profile.

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 full burden, and it only echoes two of the three parameters obliquely ('serving observation'→servings, 'meal key'→meal_key). The most semantically loaded parameter, the source enum (explicit / correction / consumption), is never mentioned, so an agent gets no guidance on which value to choose or when.

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 ('stage recording') plus two concrete resources: a serving observation and the learned portion profile, scoped by a meal key. It is clearly distinguishable from read-side siblings like get_profile, but it does not differentiate itself from the closest sibling, prepare_log_meal_request_serving, which plausibly overlaps.

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, when-not-to-use, or alternative guidance is given. The word 'Stage' hints at a two-phase flow but the description never says the staged action must be committed via confirm_action or abandoned via cancel_action, both of which are present as siblings.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description adds useful context that the lookup is 'bounded' (consistent with openWorld=false) and the important caveat that results aren't nutrition evidence. However it never explains what 'stage' produces operationally (a pending action to confirm/cancel) or any auth/rate constraints, so added value is partial.

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 the purpose leading and the caveat trailing after a semicolon. Nothing is wasted, though a more granular breakdown of the staged result would have earned a higher mark without hurting brevity.

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

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

For a one-parameter, no-output-schema lookup tool the description covers purpose and a caveat. It omits what the staged artifact is and how it is consumed (e.g., via confirm_action/cancel_action in the sibling set), which an agent needs to complete the flow.

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?

Only one parameter (query) with 0% schema description coverage, so the schema gives no semantic help. The description implies what the lookup targets but never characterizes the query string (e.g., restaurant name, dish, location) or its 2-200 length bounds. With a single self-evident param, this is adequate but not compensating.

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 clear verb+resource: 'Stage a bounded lookup for official restaurant menu sources and visual references.' An agent knows this resolves restaurant menu material, which is distinct from the many meal/grocery siblings. It does not, however, differentiate itself from an adjacent resolution tool like resolve_barcode or resolve_amazon_products.

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 a boundary note ('results are not nutrition evidence by themselves'), which hints at when the output should not be relied on. But it never states when to call this versus alternatives, nor any prerequisite such as needing a restaurant/query first. Usage is left to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=false, and destructiveHint=false, so the safety envelope is covered. The description adds useful context ('stage', retrying, private support tracker), but says nothing about the non-idempotent retry risk or what confirm/cancel does next.

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 the action front-loaded and no filler. Minor jargon ('ReceiptCal') aside, every phrase 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?

For a staging/mutation tool with no output schema, the description is minimally adequate: annotations cover the safety profile and the description conveys intent. It omits the confirm/cancel follow-up and the non-idempotent retry behavior, which an agent needs to use 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 single report_id parameter has 0% schema description coverage; the UUID regex conveys format but no meaning or provenance. The description refers to 'a failed ... customer report' implicitly, but never clarifies that report_id must identify that failed report, so meaning is largely left to inference.

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

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

The description names a specific verb (stage retrying), resource (a failed ReceiptCal customer report), and destination (the private support tracker), so the agent can distinguish it from prepare_create_customer_report. It doesn't explicitly name the differing sibling, but the 'retry a failed report' framing is distinctive.

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 stated alternatives. It implies applicability only to already-failed reports, but the agent is not told how this differs from prepare_create_customer_report or get_customer_report_status, nor that staging likely precedes confirm_action.

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

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false) already cover the safety profile, so the bar is lower. The description adds the useful boundary that this stages a retailer handoff and never places an order, but says nothing about auth/permissions, idempotency of a retry, or what state is changed by staging.

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

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

Two tight sentences, front-loaded with the action and followed by the key constraint. Every clause carries information; nothing is padded.

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

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

For a simple one-parameter staging tool with annotation coverage, the purpose and the 'never places an order' boundary are adequate. However, it omits any hint about the prepare/confirm flow (siblings confirm_action/cancel_action exist) or what a successful stage produces, leaving a real gap.

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?

A single parameter (meal_request_id) at 0% schema description coverage; the schema itself only supplies a UUID pattern. The description ties the ID loosely to 'a saved meal request' but adds no format, source, or lookup guidance beyond the pattern.

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+resource: 'retrying the configured provider for a saved meal request.' An agent can tell it acts on a saved meal request via a shopping provider. It does not, however, name or exclude any sibling (e.g., prepare_create_meal_request, prepare_retry_customer_report), so differentiation relies on the tool name.

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 explicit when-to-use or when-not-to-use guidance relative to siblings like get_meal_request or prepare_create_meal_request. The phrase 'it never places an order' scopes the behavior but does not route the agent among alternatives or state prerequisites.

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