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

No annotations are provided, so the description carries the entire behavioral burden. It discloses one genuinely useful trait — that the 24h purchase limit is server-enforced — but says nothing about read-only vs. mutating nature, authentication requirements, or whether the balance is live or cached.

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

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

It is a single economical clause with no padding, but it is a sentence fragment that leads with a data label rather than an action, so the most important information (what the tool does) is not front-loaded. Being terse here shades into under-specification rather than disciplined conciseness.

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 zero parameters and no output schema, the description does the minimum by enumerating the three returned values, which is helpful. It still omits the operation type and any behavioral or auth context that missing annotations would normally require.

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 for the description to explain; baseline 4 applies. The description correctly does not waste space on inputs.

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

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

The description names the specific data the tool surfaces (CZK credit, subsidy vouchers, 24h purchase-limit usage), which does distinguish it from siblings like orders or minutkas. However, it is a bare noun phrase with no verb, so the agent must infer that this is a read/retrieval operation rather than, say, a mutation of account credit.

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 tool, when not to, or which sibling to prefer for related questions (e.g. orders vs. balance). The agent has to infer usage purely from the returned-field list, and there are no prerequisites or exclusions mentioned.

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

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

With no annotations, the description carries the full burden and does disclose the important traits: this mutates state by spending credit, it is gated on user confirmation, and it enforces a price guard ('fresh price cannot exceed max_price') suggesting a re-check at execution time. It omits irreversibility/refund behavior and what happens when the guard trips, which keeps it from 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 sentences, zero filler, with the primary action first and the constraints after. Slight deduction because 'fresh price' is ambiguous wording that a reader must interpret as a re-fetched price.

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

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

This is a financial mutation with 5 parameters, no annotations, no output schema, and 0% schema coverage — the highest-burden case. The description covers the safety story but leaves the identifier parameters and the return/failure behavior undocumented, so an agent cannot call it confidently from the definition alone.

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 must compensate and largely does not. It clarifies max_price (price ceiling) and hints at confirmed via 'user must confirm', but day, canteen, and menu_id have no meaning, format, or source given anywhere.

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 ('buy exactly one menu item') and adds the payment mechanism ('spend credit'), which separates it from browse-oriented siblings like menu, suggest_meals, and watch_meal. It does not name a sibling explicitly, so it stops short of 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?

'User must confirm' implies a two-step flow and is a real precondition, but the description never states when to choose this over watch_meal (monitor price) or cancel_meal, nor what to do when the price cap fails. Usage is implied rather than spelled out.

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

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

With no annotations, the description must carry the full behavioral burden. It adds two meaningful constraints, the full-refund window and refusal to silently sell on burza, but leaves unclear what 'confirmed' controls, whether cancellation is reversible, what permissions are required, and what side effects occur.

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

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

The description is short and front-loads the key cancellation constraint. The second clause is concise but uses opaque 'burza' terminology that slightly reduces 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 mutation tool with no annotations, no output schema, and no parameter descriptions, the definition is substantially incomplete. It omits the required order_id semantics, the role of confirmed, error conditions, and the effect of cancellation on the order.

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 order_id or the confirmed flag, including the important fact that confirmed defaults to false.

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 ('Cancel') with a clear scoping constraint ('only within the full-refund window'), and the tool name supplies the meal resource. It does not explicitly define the sibling relationship to sell_on_burza, but the behavior note hints at 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?

It gives an explicit eligibility condition for cancellation and implies what happens outside that window. It does not name a recommended alternative action such as sell_on_burza when the refund window has passed.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral fact: already-executed orders survive watch cancellation. However, it says nothing about what happens if the watch_id is unknown, whether the call errors on an already-fired watch, or whether cancellation is idempotent — all material for a mutation tool with zero annotation coverage.

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

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

One short sentence with the action front-loaded and the caveat second — no wasted words. It is arguably too terse for the mutation it performs, but nothing in it is 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 one-parameter, no-output-schema tool this is close to sufficient, and the disclosure about purchased orders is the key behavioral nuance. What is missing is provenance for watch_id and the failure mode for an invalid or already-completed watch, which an agent needs to call it reliably.

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 watch_id has 0% schema description coverage, and the description never mentions it or explains where an agent obtains a valid watch id (presumably from watch_meal or list_watches). The description therefore leaves the only required parameter completely 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?

"Stop waiting for a meal" names a concrete action on the watch resource introduced by the sibling watch_meal, and the negative clause separates it from order cancellation. It never uses the word 'watch' in the positive clause, so the mapping relies on the tool name and the sibling watch_meal, but the intent is still 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?

It states an explicit when-not condition: this does not cancel an order the watcher already bought, which steers the agent away from using it to undo a purchase. It stops short of naming cancel_meal or orders as the alternative, so the routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden, and it does supply one genuinely non-obvious domain fact: watches in needs_review never retry automatically after uncertain purchases. However, it never states that this is a pure read with no side effects, nor whether results are paginated or bounded, and other watch states are left unexplained.

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?

Only two clauses, so there is no padding, and the resource is front-loaded. But the compression is aggressive to the point of being cryptic — 'Durable watch status/outcomes' is a noun fragment that costs the reader more than a short verb phrase would.

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 presence of an output schema means return values need not be explained, and zero parameters keeps the call surface simple. Still, for a zero-annotation tool the description omits the read-only nature, the full set of watch states, and any scoping of what 'watches' covers, leaving meaningful 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The absence of parameters is consistent with a plain list/status retrieval.

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

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

The fragment 'Durable watch status/outcomes' identifies the resource (watches) and roughly what is returned (status and outcomes), but supplies no verb, so an agent must infer from the name that this is a read/list operation. It does not distinguish itself from siblings like cancel_watch or watch_meal beyond the implicit read semantics.

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 tool, no prerequisites, and no mention of the alternatives in the sibling set (watch_meal, cancel_watch, menu, orders). The needs_review clause is a behavioral fact, not usage guidance, so the agent is left to infer 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?

With no annotations, the description carries the full burden; it discloses the important default time window (last year) and that only consumed/settled transactions are returned, which is genuine behavioral context. It says nothing about result ordering, volume, or pagination limits for what could be a year of history.

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 core scope front-loaded and the sibling disambiguation trailing. No filler, though the parenthetical phrasing is slightly cryptic.

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?

An output schema exists, so return values need not be explained, and the default window is covered. However, with no annotations and two undocumented date parameters, an agent still lacks the date format and result-size expectations needed to call this confidently over a long history.

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% – `since` and `until` have only titles and a string/null anyOf, with no format, timezone, or inclusivity guidance. The description only indirectly touches `since` via the 'default last year' note and adds nothing about `until` or the expected date string format.

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 resource (consumed meals/transactions from account history) and scopes it clearly. It also explicitly separates itself from pending orders, which maps to the sibling `orders` tool, so the agent can distinguish 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?

The parenthetical '(default last year)' and 'pending orders are separate' imply when to reach for this tool versus `orders`, but no alternative is named explicitly and no conditions for choosing `meal_statistics` or `orders` are stated. Usage is inferable rather than prescribed.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only aggregation over historical transactions, but it does not explain date-default behavior, permissions, output shape, or how empty/missing data is handled.

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 single sentence is compact and front-loaded, but its fragmentary style makes it less clear than a well-structured sentence naming the operation. It is concise without being sufficiently 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?

With no annotations, no output schema, and completely undocumented parameters, the description is too thin for a statistics tool. It lists some dimensions but does not explain the aggregation behavior or how the date filters shape the results.

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

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

The schema has two date-range parameters with 0% description coverage, and the description does not name 'since' or 'until', their accepted date formats, or what happens when they are omitted. The word 'historical' only weakly implies temporal filtering.

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 lists the dimensions covered (spending, favourites, canteens, weekdays) and the data source (historical transactions), which hints at an aggregation/reporting tool. However, it is a sentence fragment without a clear verb, and it does not distinguish this tool from siblings such as meal_history or orders.

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 meal_history, orders, balance, or other siblings. The phrase 'actual historical transactions' implies it is not a live-menu tool, but no alternatives or exclusions are 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?

With no annotations, the description carries the behavioral burden. 'No purchase' usefully discloses that this is a non-transactional read operation, and it lists the visible menu data, but it does not mention authentication needs, defaults, rate limits, or failure behavior; the output schema covers return values.

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 definition is a single front-loaded sentence with no wasted text. It puts the core action first and then adds only relevant scope and a non-purchase caveat.

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 menu tool with an output schema, the description adequately states purpose and included content. However, given zero annotation coverage and zero schema descriptions, it leaves the two input parameters and usage routing under-explained.

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 should compensate for the undocumented 'day' and 'canteen' parameters. It never mentions either parameter or the default canteen, adding no meaning beyond the bare 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 uses a specific verb and resource ('List menu') and names the included content: sold-out dishes, soup variants, price, and burza deadlines. The phrase 'no purchase' also distinguishes it from transactional siblings such as buy_meal and orders.

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 an implied exclusion ('no purchase'), which helps separate browsing from ordering. However, it does not explicitly say when to use this instead of siblings like buy_meal, meal_history, or minutkas, nor how day/canteen choices affect use.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose a meaningful behavioral constraint: availability is direct-sale only, with no guaranteed stock and no online reservations. That preempts a wrong assumption that the listed items can be reserved online. It stops short of stating read-only nature, auth needs, or freshness/latency of the published 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?

Two short sentences with no filler, and the availability caveat is placed immediately after the subject. The opening noun is jargon, which slightly undercuts front-loading, 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?

An output schema exists, so return values need not be described. But with zero annotation coverage and 0% schema description coverage, the definition leaves the agent without parameter semantics, without a definition of 'minutky', and without any link to the overlapping 'menu' sibling. For a two-parameter listing tool that is a substantive 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 compensate, and it says nothing about either parameter. It does not explain the expected format of 'day' (date? weekday name?) or what values 'canteen' accepts beyond the default 'harcov'. The one useful hint, that results are scoped to a canteen, is only inferable from the schema itself.

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?

It names a specific resource (the published 'minutky' menu) and adds a scope caveat, so an agent knows roughly what it returns. However, 'minutky' is unexplained domain jargon and the description never distinguishes this from the sibling 'menu' tool, leaving genuine ambiguity about which listing 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 and no mention of alternatives, even though a sibling tool named 'menu' plainly overlaps. The only usage signal is implicit in the phrase 'published ... menu' and the 'direct-sale only' caveat, which tells the agent what not to expect rather than when to call it.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real content beyond the (empty) schema by telling the agent that cancellation effects and deadlines are surfaced alongside the orders, which matters before calling cancel_meal. However, it never states that this is a guaranteed read-only, side-effect-free operation, nor does it describe scope or any auth requirement, which is the key gap for an unannotated tool.

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

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

A single compact sentence with the resource front-loaded and no filler. It is efficient, but the trailing 'with cancellation effects/deadlines' is compressed to the point of ambiguity, so it reads as under-specified in places rather than maximally tight.

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 output schema already covers return shape and there are no parameters, so much of the burden is lifted. What remains unexplained is behavioral: whether the call is read-only, what 'burza offers' refers to, and what 'cancellation effects' actually means in the response — enough gaps that an agent knows the tool's topic but not its full contract.

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

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

The input schema has zero parameters, so there is nothing for the description to disambiguate; per the baseline rule this sits at 4. Nothing in the description falsely implies filtering options 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 ('List') and two concrete resources ('current meal orders' and 'own burza offers'), plus the ancillary cancellation/deadline info returned. It is distinguishable from history-oriented siblings such as meal_history and from mutating siblings such as cancel_meal, though the jargon 'burza' and the ambiguous 'cancellation effects' leave small gaps.

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 'current' implies this is the live-state counterpart to meal_history, but that routing is left to inference rather than stated. There is no explicit 'use this when…' sentence and no mention of prerequisites or when a different sibling (e.g. minutkas, balance) is the better call.

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

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

With no annotations, the description carries the full load, and it does disclose the key risk: credit only returns if someone buys it. It still omits what happens to the meal/order while listed, whether the listing can be undone, and whether the action is irreversible — material for a marketplace mutation.

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 timing constraint and the payoff condition both front-loaded. Nothing could be cut without losing 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 side-effecting marketplace tool with no annotations, no output schema, and zero parameter documentation, the description is too thin. It never explains the order_id/confirmed arguments or what state the order ends up in, so an agent could call it incorrectly even while understanding the general idea.

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, and the description explains neither. In particular the 'confirmed' boolean (default false) is left completely opaque — an agent cannot tell whether it gates a confirmation prompt, forces the sale, or is required for the call to succeed.

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 ('offer your own meal on burza') plus a timing condition ('AFTER refund cutoff'), which is far more than a restatement of the name. It implicitly contrasts with withdraw_from_burza and buy_meal, though it never names the sibling that reverses this action.

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

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

The phrase 'AFTER refund cutoff' gives one real precondition for use, which is useful guidance. However, there is no explicit statement of when NOT to use it or of the alternative tool (withdraw_from_burza) for undoing a listing, so the agent must infer the routing.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states the tool only suggests and never buys, explains inference from history, ranking by previous orders, absence of timeslots, default soup inclusion, and that missing or closed menus are not invented. These are substantive behavioral traits beyond the schema.

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

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

The description is compact and front-loads the core purpose before adding constraints. Some phrases are telegraphic, but nearly every clause carries useful information about scope, ranking, defaults, or unavailable menus.

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 behavioral context is strong for a tool with no annotations, but the definition is not fully complete: it leaves key parameter semantics for 'days' and 'start' undocumented, and there is no output schema or return-shape explanation. It is adequate for understanding the tool's intent, but not fully self-contained.

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 for all three parameters. It partially clarifies lunch behavior via 'lunch' and 'lunch_no_soup,' but it does not explain the 'days' default of 14, the 'start' parameter, or how those parameters shape the suggestion range.

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

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

The description uses a specific verb and resource: 'Suggest lunch + dinner for each day.' It also immediately distinguishes the tool from purchasing siblings by saying 'never buy,' and clarifies that results are ranked by previous orders rather than being raw menus or order history.

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

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

The description gives clear usage context and boundaries: it is for suggestions, never purchases, has no timeslots, and requires explicit 'lunch_no_soup' selection when soup should be omitted. It does not explicitly name sibling alternatives such as buy_meal or menu, so the routing guidance is clear but not fully comparative.

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

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

With no annotations, the description carries the behavioral burden and discloses important traits: polling about every 20 seconds rather than instant, no substitution of another dish, no purchase above `max_price`, and a 14-day timezone-aware expiry. It omits what happens on cancellation and does not explain the optional `confirmed` flag, leaving some significant behavior 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?

The purpose is front-loaded in the first sentence, followed by actionable constraints with no filler. Every sentence contributes either routing, parameter sourcing, or behavioral expectation.

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

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

This is a complex 8-parameter authorization tool with no annotations, 0% schema description coverage, and no output schema. The description covers the core purpose and several key constraints, but it does not explain all parameters or describe what the tool returns after creating the watch, so it is only partially complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for `section`, `number`, and `name` by saying to copy them from the menu, and explains `expires_at` constraints and `max_price`, but it leaves `canteen`, `day`, and `confirmed` 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?

The description gives a specific action and scope: 'authorize ONE future automatic burza purchase of this exact sold-out dish.' It clearly distinguishes this from an immediate `buy_meal` by emphasizing future, automatic, exact-dish, sold-out behavior.

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

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

The phrase 'sold-out dish' and 'future automatic' establish the usage context, and the description instructs how to source fields: 'Copy section/number/name from menu.' It does not explicitly name when to use `cancel_watch` or `list_watches`, nor does it state when not to use this tool, so it falls short of full alternative routing.

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

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

No annotations are provided, so the description carries the full burden. It discloses the restore-as-meal-order side effect, but says nothing about what happens if the offer was already sold, whether the withdrawal is reversible, what authorization is needed, or what the 'confirmed' flag does (dry-run vs commit).

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 no filler, and the key outcome is front-loaded after the action. It is efficient, though so terse that it leaves the two parameters 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 state-mutating tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin: it omits the role of 'confirmed', the failure mode for already-sold offers, and any permission or irreversibility notes.

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 of the two parameters is mentioned in the description. 'exchange_id' is only obliquely implied by 'your offer', and the boolean 'confirmed' parameter (default false) — likely a commit/dry-run switch — is completely undocumented anywhere.

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 ('withdraw') and resource ('your still-unsold offer from burza'), plus the resulting state change ('restore it as your meal order'). It is clearly the inverse of sell_on_burza, though that sibling is not named explicitly.

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

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

The phrase 'still-unsold' implies the precondition that the offer has not yet been matched, which hints at when this tool is valid. However, no alternative is named (e.g. cancel_meal vs withdraw_from_burza) and there is no explicit when-not guidance.

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