Forkmate

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

Despite annotations already carrying destructiveHint and idempotentHint, the description adds substantial unstated behavior: permanence with no undo, the cascade where deleting the last food removes the entry, and the fact that a non-matching `id` errors and deletes nothing. These are exactly the edge cases an agent needs before calling a destructive tool.

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

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

The deletion semantics are front-loaded and efficient, but the trailing multi-clause disclaimer about calorie/macro estimates from USDA, Open Food Facts and AI estimates has no bearing on a delete operation and consumes roughly half the text. That is off-topic filler in an otherwise tight definition.

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 a rich annotation set and an output schema present, the description supplies everything still needed: scope selection, permanence, cascade-to-entry-removal, and error behavior. Nothing required to invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, so `id`, `item_index` (0-based, omit to delete the whole entry) and `local_date` are already fully documented. The description restates the same semantics (item_index selects a food, omission targets the entry) without adding format or boundary details beyond the schema, so the baseline 3 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?

The first sentence states a specific verb and resource ('Delete one food from a diary entry ... or the whole entry') and distinguishes the two scopes by the presence or absence of `item_index`. An agent can separate this from siblings like log_meal, update_meal, and get_day without opening any schema.

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

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

It clearly states the two operating modes and the condition that selects each ('by item_index' vs 'without it'), plus the not-found error case, which is genuine when-to-use guidance. It does not name update_meal as the non-destructive alternative, so it stops short of explicit 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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: the exact shape of the returned data (entries with ids, item_index, quantity, macros, totals) and the critical caveat that values are estimates from varied sources and unsuitable for medical decisions.

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

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

Front-loaded with the core action and return shape, then the disclaimer. The disclaimer is long but each clause (sources, approximation, medical exclusions) carries distinct information, so it is mostly earned rather than 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?

With annotations covering safety, an output schema covering return values, and 100% parameter coverage, the remaining burden is domain caveats — which the description handles thoroughly by disclosing data provenance and medical limitations. Nothing an agent needs to call it correctly is missing.

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

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

Only one parameter, and schema coverage is 100%, so the schema fully documents local_date's format and default. The description's "one day" phrasing hints at the date scope but adds no syntax or defaulting detail beyond the schema, matching the 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 and resource ("Read the user's food diary") and scopes it precisely to "one day," which implicitly separates it from get_range and the mutation siblings. It doesn't name an alternative explicitly, so it falls just short of the top tier.

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 one-day scope implies when to use it versus get_range, and the closing disclaimer clearly rules out medical uses (insulin dosing, glucose prediction). However, there is no explicit when-to-use or when-not-to-use routing to the sibling tools, leaving usage largely inferential.

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?

Goes well beyond the annotations by disclosing two non-obvious behaviors: "reading marks nothing as read" (the annotations only say read-only, not that unread state is preserved) and a 180-day retention cutoff that affects what can be returned. It also surfaces that the reply carries an unread count, which matters for how an agent reports results.

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

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

Front-loads the core action and keeps to a few dense sentences with no filler. Mild redundancy in enumerating per-notification fields (kind, title, body, link, day, unread) that the output schema already defines, which costs it the top score.

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 annotations carrying the safety profile and an output schema carrying the return shape, the description covers everything else an agent needs: content kinds, ordering, non-mutating read semantics, retention limits, and the unread count. Nothing material is missing.

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

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

Schema coverage is 100% and both parameters (limit with 1-20 bounds and default 10, unread_only defaulting false) are fully documented in the schema. The description adds nothing to either parameter beyond restating the newest-first ordering, so the baseline 3 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 precise verb and resource ("Reads the user's Forkmate notifications") plus the ordering ("newest first") and enumerates the three kinds of content returned. No sibling tool deals with notifications, so the agent can route unambiguously 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?

Usage is only implied: the description says what notification kinds exist, which hints at when it is useful (checking fixes, release notes, account messages), but it never states a when-to-use condition or any exclusion, and points to no alternative. Adequate but not 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?

Beyond the annotations' read-only safety profile, the description discloses important behavioral caveats: allergies are self-reported and not a safety guarantee, the response includes an allergy_disclaimer, and likes/dislikes are taste preferences rather than restrictions. These are exactly the kind of semantic warnings an agent needs before relying on the returned 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?

The description is three sentences, front-loaded with the core purpose and followed by two clearly relevant caveats. Every sentence earns its place and there is no redundant or filler content.

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 read-only tool with annotations and an output schema, the description covers the key return semantics and the critical allergy caveat. The output schema can carry structural return details, so no further explanation is required for correct invocation.

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

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

The tool takes zero parameters, so there is no parameter semantics to document in the description. The baseline for a parameterless tool is 4, and nothing in the description misleads about input requirements.

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 ('Read') and resource ('the user's food profile'), then enumerates the returned fields: diet style, allergies, likes, dislikes, and portion note. It is clearly distinguishable from write-oriented siblings like update_preferences in practice, but it does not explicitly name or contrast any alternative tool.

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 says what is read but gives no explicit when-to-use condition, prerequisites, or comparison to alternatives such as update_preferences or get_usual_foods. An agent must infer that this is the read path for 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 already cover the safety profile (readOnlyHint=true, non-destructive, closed-world), and the description adds meaningful context beyond them: the data provenance (USDA FoodData Central, Open Food Facts, user or AI estimates) and an explicit warning that values are not suitable for insulin dosing or glucose prediction. That is genuine domain-specific behavioral disclosure, not restatement of 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?

Front-loads what the tool returns before the disclaimer, which is the right order for an agent. The second sentence is long and somewhat repetitive in its list of prohibited uses, but each clause carries distinct safety meaning rather than 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?

An output schema exists, so return values need not be re-explained, and the description still summarizes them usefully while adding the estimate caveat. For a two-parameter read tool this is effectively complete; only the missing routing guidance to get_day 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?

Schema description coverage is 100% and both start/end are documented as inclusive YYYY-MM-DD, so the baseline is 3. The description adds no format or boundary semantics of its own.

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 ('the user's food diary') plus the scope and return shape (per-day totals, each entry with its `id`). This clearly distinguishes it from the single-day sibling get_day, though it never names 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?

Usage is implied by 'across a date range' and the required start/end parameters, but the description never says when to prefer this over get_day or how it relates to the other diary tools. No exclusions or alternatives are offered, 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?

Annotations already establish read-only, non-destructive, closed-world behavior, and the description adds substantial context on top: the provenance of every calorie/macro value (USDA FoodData Central, Open Food Facts, user entry, AI estimate), the fact that values are approximate and not batch- or package-specific, and an explicit prohibition on medical use such as insulin dosing or glucose prediction. This is exactly the kind of behavioral disclosure annotations cannot carry.

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

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

Front-loads the purpose, then mode details, then the filter interaction, then the safety caveat — a logical progression with no filler. The disclaimer is long but every clause (provenance, approximation, medical unsuitability) earns its place for a nutrition tool.

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

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

Given a single optional enum parameter, an existing output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what each mode returns, how the filter applies, and the reliability limits of the data. Nothing material is missing.

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

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

Schema coverage is 100%, so the `meal` enum is already documented as 'Only foods logged under this meal.' The description adds real meaning beyond that by clarifying the filter applies to BOTH the usual and recent lists, which the schema alone does not convey. Baseline 3 is exceeded but no format or default nuance 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 and resource (read what the user usually/recently eats) and cleanly splits the tool into two named modes, `usual` and `recent`, with the exact fields each returns. It does not, however, distinguish itself from siblings like search_foods or get_day, so an agent must infer the boundary from the mode semantics 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?

The description makes the trigger conditions for each mode implicit but clear: `usual` for most-logged foods, `recent` for the last seven days, and `meal` to narrow either. There is no explicit when-not guidance or named alternative (e.g., when to prefer search_foods or get_range), so usage is inferred rather than 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 only declare non-read-only, idempotent, non-destructive; the description adds the substantive behavior the agent could not otherwise infer: it persists consent version, timestamp, connected app and the user's words, and then logs any meal that was waiting on consent. It also flags the authority constraint (assistant consent invalid) and where withdrawal lives, which matters for a health-data write.

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 opening clause front-loads the core action and the constraints follow in priority order with no filler. The phrase 'as summarised in the consent text that a refused log reply shows' is slightly convoluted, but no sentence is extraneous.

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 two-parameter mutation with a rich annotation profile and an output schema, the description covers purpose, authority constraint, side effects (storing fields then logging a pending meal), and off-ramp (Settings withdrawal). Nothing an agent needs to invoke it correctly is left implicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: user_statement must be the user's verbatim words rather than a paraphrase, and version corresponds to the consent text shown in the refused reply. That constrains how the agent fills the enum and the free-text field beyond the schema's own wording.

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: recording the user's consent to Forkmate storing/processing health-related data. It also anchors the action in a concrete trigger (the consent text shown by a refused log reply), so the agent knows exactly which resource this mutates and how it differs from every sibling (log_meal, get_preferences, etc.).

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 a clear admissibility condition — only the user's own explicit agreement in this conversation counts, and an assistant agreeing on their behalf is not consent — plus a redirect for the opposite operation (withdrawal happens in Forkmate Settings). That covers when to use and when not to, though it doesn't name a sibling tool for the non-consent paths.

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?

Goes well past the annotations (which only say it's a non-idempotent, non-destructive write) by disclosing the reply contents (`id` and `local_date` for later edit/delete), the recipe-substitution behavior, the `said` portion-checking behavior, and the provenance/estimate semantics including an explicit medical-use caveat. This is exactly the kind of context annotations cannot carry.

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

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

Front-loaded with the core action and return value before moving to edge-case behaviors and disclaimers; each sentence carries information. The macro-source/medical disclaimer sentence is long and dense, which slightly dilutes scannability.

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 7-parameter mutation tool with an output schema, nothing essential is missing: it covers write semantics, what identifies the new entry, portion validation, recipe handling, provenance defaults, and the estimate/medical caveat. An agent can call it correctly and know what to tell the user afterwards.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the recipe-in-one-item convention, the role of `said` in validating amounts, and the fact that all macro values are approximations from named sources. It adds value beyond field-level schema text.

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

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

Opens with a specific verb+resource: 'Add a meal to the user's food diary', and enumerates what a meal consists of (items, optional label, date, note, source). This clearly separates it from update_meal and delete_meal, which act on an existing entry.

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 concrete operational guidance: how to handle restaurant meals (numbers depend on menu item/size/add-ons), how to log saved recipes (send the user's words as one item's name with amount in quantity), and how portions are validated against `said`. It stops short of explicitly routing between siblings (e.g., when to search_foods or lookup_barcode first, or when update_meal is the right call instead).

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

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

Annotations only cover safety (readOnly, openWorld, non-destructive), but the description goes well beyond them: it names the data provenance chain (USDA FoodData Central, Open Food Facts, user entry, AI estimate), labels values as approximate estimates rather than lab-measured, warns that they may not be package- or batch-specific, and explains what fields are returned including serving_grams/serving_label.

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

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

Front-loads purpose, then return contents, then the limitation caveat — a sensible ordering. The final disclaimer is long and runs several distinct warnings together, but every clause is substantive rather than 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?

With an output schema present the description need not enumerate return values, yet it helpfully previews them, and it fully covers the domain-critical caveat about estimate quality. The only gap is not routing the agent to search_foods for cases where a barcode is unavailable or unknown.

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

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

Schema description coverage is 100% — the single `upc` parameter already documents 'digits only (8–14 digits)'. The description adds the UPC/EAN equivalence but no format, validation, or failure semantics for unknown barcodes, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('look up a packaged food by its UPC/EAN barcode') plus the backing source (Open Food Facts), which is enough for an agent to distinguish it from the name-based search_foods sibling. It never names that alternative explicitly, so the differentiation is inferable 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?

Implied trigger is clear (you have a barcode), and the description supplies a firm usage boundary: results are not suitable for insulin dosing, carb counting, or blood-glucose prediction. It does not tell the agent when to prefer search_foods instead when no barcode is available, so routing guidance is incomplete.

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?

Beyond the readOnly/openWorld annotations, the description discloses return shape (up to 5 candidates, macros per 100 g, source labels, serving fields, provenance caveats), the unverified 'product label' status, the absence of paging, and a strong medical-use disclaimer. This is rich context an agent cannot get from annotations alone.

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

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

Front-loaded with the sources, but it is one dense run-on paragraph with redundant source enumeration ('USDA FoodData Central, Open Food Facts, the user's own entry or an AI assistant's estimate') and a deeply nested parenthetical about the 'product label' source that is hard to parse.

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?

Despite an output schema already defining the return, the description supplies enough for correct invocation: sources, candidate cap, query rules, and the medical caveat. Only the provenance/portion-caveat behavior remains vague.

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

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

Schema coverage is 100%, so both parameters are already documented; the description's query constraints (2-letter minimum, no wildcards, no paging) largely restate the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (Search) plus the exact corpora it searches (USDA FoodData Central, Open Food Facts, Forkmate's curated restaurant menus) and the query unit (a named food). This clearly distinguishes it from siblings like lookup_barcode and get_usual_foods.

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 establishes context (queries name a food, min 2 letters, no wildcards, no paging, generic-dish behavior) but never names an alternative or states when NOT to use it — e.g. telling the agent to reach for lookup_barcode when a barcode is available.

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?

Goes well beyond the annotations: it discloses that nothing in the diary is modified, that the note is stored in the user's own account and deleted with it, and that no reply is sent. These retention and side-effect facts are exactly the kind of context readOnlyHint/destructiveHint cannot express, and they are consistent with destructiveHint=false and openWorldHint=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?

Front-loaded with the core action and the user's-words constraint, then the side-effect and retention facts. Four sentences that each carry information, though the final sentence could be tightened slightly.

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 a 4-parameter schema at full description coverage, an output schema in place, and annotations covering the safety profile, the description supplies the remaining essentials (verbatim input expectation, no diary mutation, retention, no reply). Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and three of four parameters carry enum descriptions, so the schema already documents about/category/rating/message fully. The description restates the feedback kinds that mirror the category enum but adds no format or usage detail beyond the schema, which is the baseline-3 case.

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

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

States a specific verb+resource ('Sends feedback to Forkmate') and enumerates the four feedback kinds, so an agent can tell exactly what this tool does and that none of the siblings (delete_meal, log_meal, update_meal, etc.) perform 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?

Gives a clear selection condition: it is for feedback the user has asked to send, verbatim in the user's own words rather than a paraphrase, and it changes nothing in the diary. There is no competing sibling to exclude, so the absence of named alternatives costs little.

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 (readOnly=false, destructive=true, idempotent=true), and the description adds substantial non-obvious behavior: partial-update merge semantics, no history kept, the quantity-rescaling rule with the '150 g to 300 g doubles' example and its fallback, and the immutability of the entry's date. That is exactly the extra context annotations cannot carry.

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

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

Front-loaded with the core purpose and edit surface, then layered with the rescaling rule and the estimate disclaimer. It is dense and earns most of its length, though the closing medical disclaimer is lengthy relative to the tool's edit function.

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 an 11-parameter mutation tool with nested macros, the description covers identity (id/local_date/item_index), merge semantics, the rescaling edge case, and the accuracy caveat. An output schema exists, so return-value explanation is not needed, leaving no material 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 coverage is 100% so the baseline is 3, but the description goes beyond the schema by explaining cross-parameter interactions: quantity without macros rescales macros/caffeine/fluid, and `said` is the verbatim user wording that amounts are validated against. It does not explain every parameter (e.g. `note` replacement scope is left to the schema).

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

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

The description opens with a specific verb+resource ('Correct a food already in the user's diary') and enumerates exactly what is editable (name, quantity, macros, caffeine, fluid, meal label, note). This clearly separates it from siblings like log_meal and delete_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?

It states when to use the tool and the key routing rule between entry-level vs food-level edits ('Required when changing a food's name/quantity/macros/caffeine/fluid; omit for an entry-level change'), plus the constraint that an entry cannot be moved to another day. It never names an alternative sibling such as log_meal or delete_meal, so it falls 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?

Adds extensive behavior beyond the annotations: partial-update semantics, case-insensitive removal matching with not_found reporting, cross-field side effects (adding a like drops the dislike), list caps of 50 items/80 chars, consent exemptions for removals, and the approval workflow including the server's inability to verify a human approval. This is exactly the disclosure a destructive mutation 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?

Long, but the length is justified for an 8-parameter destructive mutation with an approval gate, and the core purpose is front-loaded. Some approval wording is repeated across the description and the user_approved schema field, and the Forkmate Settings sentence is marginal, keeping it from a 5.

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

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

For a high-complexity tool with an output schema, it covers everything an agent needs: mutation scope, consent rules, list limits, conflict resolution, and a brief note that the reply is the whole updated profile. Nothing material is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds genuinely new semantics: attention to partial updates, the add-to-likes/remove-from-dislikes interaction, and how removals match saved names by casing. It does not re-explain individual parameter formats, which the schema already handles.

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 ("Edit the user's food profile") and enumerates the exact operations: add/remove likes and dislikes, add/remove allergies, set diet style. Combined with "Only the fields sent change," an agent can immediately distinguish it from the read counterpart get_preferences without opening a schema.

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

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

Gives real usage context: it saves only what the user states about themselves, not diary inferences, and describes the approval gate that must precede a successful call. It stops short of explicitly naming the alternative (e.g. get_preferences for reading) or when-not-to-call, so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing what it does NOT return (no account id, email or identifier), preempting a common misuse expectation.

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 diagnostic purpose and followed by the key output caveat. No wasted words.

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

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

For a no-parameter diagnostic with an output schema and full annotation coverage, the description supplies the essential behavioral caveat. It is complete enough to invoke correctly, with only the absence of explicit usage routing as 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 to document and the baseline is 4. The description does not need to compensate for any parameter 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+resource: a diagnostic that confirms the connection is signed in to a Forkmate account. It is clearly distinguishable from the food-logging siblings, though it does not explicitly name or contrast 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 word 'Diagnostic:' implies usage as a connectivity/auth check, but there is no explicit when-to-use, when-not, or relationship to alternatives like get_preferences. Context is implied rather than stated.

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