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

With no annotations, the description carries the full burden of disclosing behavior. It reveals that macros are per 100g, explains the two source options (verified vs estimated) with a recommendation, and states that the new product id is returned. However, it does not mention error cases, duplicate handling, or any required permissions, which would be expected for a mutation tool.

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

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

The description is four short sentences, each providing distinct value: purpose, unit context, source semantics, and return value. It is front-loaded with the action and avoids any filler or repetition of schema details.

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

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

For a 12-parameter creation tool with no annotations, the description covers the most important context: units, source trust levels, and the return value. It is not exhaustive (e.g., no duplicate handling), but the provided information is sufficient for an agent to correctly invoke the tool in most scenarios.

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

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

Schema description coverage is 0%, but the description compensates by explaining the meaning of the nutritional fields ('Macros are per 100g') and clarifying the source parameter ('verified' from package label, 'estimated' from general knowledge). This adds significant value beyond the bare schema. It does not individually describe optional fields like salt or fibre, but the per-100g context applies to all.

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 action and resource: 'Add a Product to the Catalog.' This clearly distinguishes it from siblings like find_product, log_food, and delete_food_entry. The verb 'Add' and object 'Product/Catalog' make the tool's function unambiguous.

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

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

The description provides clear context for when to use this tool: when adding a product to the catalog. It does not explicitly name alternatives or exclusions, but the phrasing 'Add a Product to the Catalog' makes the intended use obvious among the listed sibling tools. The additional notes on units and source further clarify correct usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It simply restates the tool name and parameter ('by id') without mentioning permanence, error behavior, authentication needs, or side effects. This is a significant gap for a deleting/mutating operation.

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 sentence with no redundant information. It is appropriately concise for a simple tool, earning every word.

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?

Although the tool is simple and has an output schema, the description lacks essential context for a mutation tool with no annotations. It does not explain irreversible effects, behavior when the id is not found, or any other operational details, making it incomplete for the given complexity.

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 says 'by id', which adds no meaning beyond the schema's 'id' property. It does not explain what the id refers to, where to find it, or any constraints, providing minimal added 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?

The description clearly states the action ('Delete') and the resource ('a Food Log Entry') with a specific criterion ('by id'). It is clearly distinct from sibling tools like add_product, find_product, and log_food, which perform different operations.

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

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

The usage is implied: you would use this tool to remove a food log entry. However, it does not explicitly state when to use it over alternatives or mention any conditions or exclusions, so it only meets the 'implied usage' level.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses substring matching, the option to list the whole catalog when query is omitted, and the id relationship with log_food. It does not explicitly mention read-only status, match limits, or case sensitivity, but covers key invocation-relevant behaviors.

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 with no filler. The first sentence defines the tool's core action, and the second provides essential usage and integration context, with the most important information front-loaded.

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

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

The tool is simple, has an output schema, and a single optional parameter. The description gives the query behavior, the optional full-list behavior, and a concrete pointer to log_food, making it sufficiently complete 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 schema provides only a titled 'query' with no description (0% coverage). The description fully compensates by explaining that the query matches by name or brand via substring and that omitting it lists the entire catalog, making the parameter's semantics clear.

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 ('Search') and resource ('Catalog') with search criteria ('name or brand (substring match)'), clearly distinguishing it from sibling tools. It also states the optional full-catalog listing behavior, further clarifying scope.

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

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

It provides clear context for use: 'Call this before log_food against a Catalog Product' and explains how the result's id maps to the expected product_id. It does not explicitly mention when not to use it or compare alternatives, but the integration guidance is strong.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that one-off entries are 'always recorded as estimated,' that 'at defaults to now,' and explains the unconventional date rule ('04:00 Europe/Amsterdam day rule, not a calendar date'). These are critical behavioral traits not inferable from 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, front-loaded with the core action, and uses clear structure. It efficiently conveys parameter alternatives, behavior, and return value in just a few sentences with 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?

Given the tool's moderate complexity (6 parameters, dual usage modes, no annotations), the description covers purpose, parameter selection, behavioral nuances, and return value. The output schema already documents the return shape, so the description's additional details on date handling and estimation status make it complete for an agent to use 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%, so the description must compensate. It explains grams, product_id (and its source), name+macros (per 100g, estimated), and at (default behavior and date rule). However, it does not explain the 'entered_as' parameter at all, leaving a gap in parameter semantics.

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

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

The description clearly states the tool's function: 'Log that `grams` of a food were eaten.' It uses a specific verb and resource, and distinguishes itself from sibling tools like find_product and add_product by focusing on logging consumption rather than searching or creating 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?

The description explicitly prescribes usage: 'Pass exactly one of: product_id (from find_product, for a Catalog item) or name + macros ... for a one-off.' This provides clear conditions for when to use each parameter combination, and implies using find_product first to obtain a product_id.

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

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

Despite no annotations, the description discloses key behavioral aspects: it is read-only, only accepts a single SELECT/WITH statement, and uses Europe/Amsterdam day boundaries for date columns. This goes beyond the basic tool name and input schema by explaining the date convention and statement restriction. It does not mention potential limits or auth, but for a query tool the provided constraints are substantial.

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 front-loaded with purpose and constraints, followed by a compact but complete schema listing. All listed tables and columns are necessary for constructing valid SQL. The date note is a single, useful addition 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?

Given the tool's complexity, the description covers purpose, statement type, schema, and date semantics comprehensively. The presence of an output schema means return-value details need not be duplicated in the description. The inclusion of the date column convention handles a common edge case that would otherwise cause incorrect aggregations.

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 coverage, the description compensates by listing the full database schema, including all tables and columns, and explicitly stating the sql parameter must be a single SELECT/WITH statement. It also provides the date grouping convention to help construct correct queries. This adds significant meaning beyond the input schema's bare string type.

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 'Read-only SQL against the health database', which clearly identifies the verb (read/query) and resource (health database). This differentiates it from sibling mutation tools like delete_food_entry or add_product. The constraint of being a single SELECT/WITH statement further clarifies its scope.

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 states the tool is read-only and requires a single SELECT or WITH statement, giving clear context for when it applies. It does not explicitly mention alternative tools or when not to use it, but the read-only scope implicitly excludes write operations, making it appropriate for data retrieval. The date grouping note adds practical guidance for constructing queries.

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?

Although no annotations are provided, the description compensates fully. It discloses that the sync is 'delta by default and cheap to call,' that full mode 're-fetches everything and reconciles deletions,' and that it also refreshes templates and measurements, revealing side effects and cost.

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?

Four sentences, each earning its place: purpose, usage timing, parameter explanation, and additional scope. The text is front-loaded with the main action and free of fluff.

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

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

For a one-parameter sync tool with no output schema, the description covers what, when, why, and the parameter's behavioral difference. It leaves no gaps that would hinder an agent from correctly selecting and invoking the tool.

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

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

Schema coverage is 0% for the single parameter, so the description must explain it. It does: 'Delta by default' (full=False) and 'full=True re-fetches everything and reconciles deletions,' adding substantial meaning beyond the bare boolean field.

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 'Pull new training data from Hevy into the database,' clearly stating the action and resource. It also notes it refreshes exercise templates and body measurements, and the sibling tools are all food/query tools, so there is no confusion about what this tool does.

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

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

Explicitly instructs to 'Call this before answering a question about recent training,' grounding when to use it. It also distinguishes delta vs full mode: 'use it only if the data looks wrong, not routinely,' providing a clear exclusion for full mode and guiding appropriate invocation.

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