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 well: it discloses the data provenance (industry-association/manufacturer published values plus 消費者庁 food-labeling standards), the citation-backed output, the five possible verdicts, and the month-only-date convention. It does not state whether the call is read-only or what the response structure looks like, but for a lookup tool this is solid.

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

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

A single dense paragraph that front-loads the purpose and verdict vocabulary before the input description. The long food enumeration is somewhat bulky but functional; nothing is wasted on 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 no output schema, the description compensates by naming the judgment categories and stating that sources are returned, which is what an agent needs to route and interpret results. It stops short of describing the actual response shape (e.g., JSON field names), so it is strong but not exhaustive.

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 all five parameters (food, date, days, frozen, opened) are already documented in the schema, including the date-format examples and 'days の代わり' relationship. The description adds the food alias/slug breadth and the month-end rule, but these duplicate or loosely restate schema content, so the baseline of 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 specific verdict-style action ('判定' of how long expired food remains edible), enumerates the resource (foods, dates, opened/unopened state) and the exact output categories (期限内／開けて確かめる／目安を超えている／食べない／期限表示の無い食品). An agent knows immediately what this does and that it differs from unrelated siblings like furusato or denki_keisan.

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 trigger queries ('賞味期限が3日過ぎた牛乳は飲める？', '開けた納豆はいつまで', '豆腐は消費期限？') and explicitly says '相談にはこれ', so the when-to-use condition is clear. It names no alternative tool, but the sibling list contains no competing food-expiry tool, so exclusion guidance is largely unnecessary.

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