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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low, and the description still adds real context: the 30-day lookback window when date is omitted, that plans never expire on their own, and that each plan carries an entryId. It does not cover ordering or result volume, which keeps it below a 5.

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

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

Three sentences, front-loaded with the core verb/resource and scope constraint, then the default behavior, then the identifier detail. It is dense with useful specifics, though the parenthetical inventory of field names (microsOrigin, garung, behandlung, notiz) is somewhat jargon-heavy for a first sentence.

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

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

With no output schema, the description carries the burden of naming return fields and does so (scheduled time, grams, macros, microsOrigin, preparation, entryId), and the zero-required-parameter case is fully explained. It lacks any statement about result ordering or size, a minor gap for a listing tool with an unbounded open-plan window.

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 a 3, but the description genuinely enriches the date parameter by describing the default behavior when it is absent (all open plans from the last 30 days onwards). Only tz is left entirely to the schema, which already explains it adequately.

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 (list the signed-in user's planned, not-yet-eaten meals) and enumerates the returned fields, which clearly separates it from consumed-meal or logging tools. It stops short of naming a sibling like joiva_list_meals or joiva_get_day as the alternative, so differentiation is implied rather than explicit.

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

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

The description implies when this applies by defining 'planned (not yet eaten)' and explains the no-date default, but it never states when to prefer this over joiva_list_meals, joiva_get_day, or joiva_confirm_planned, and gives no prerequisite or exclusion guidance.

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