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

Annotations already cover the read-only safety profile, but the description goes well beyond them: currency semantics (prices unconverted, per currencyCode), discountedPrice null semantics, badge/healthTags presence, openingHours format and closed-day handling, stats field meanings, and the { data: null } missing-case. This is rich behavioral disclosure.

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?

Purpose is front-loaded and the rest is dense but purposeful, with each clause carrying distinct semantic content. It is long, and the stats enumeration could be trimmed, but with no output schema the detail largely earns its place.

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?

There is no output schema, so the description carries the burden of describing return values — and it does: menu grouping, prices, badges, modifiers, openingHours, stats, and the null case. An agent has what it needs to call and interpret the result.

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 only 33% (includeMenu and includeModifiers have no schema descriptions), so the description must compensate. It explains includeModifiers thoroughly (option groups, min/max picks, max null = no limit, extra charge), but includeMenu is left to inference from "full menu".

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 ("Fetch one GrabFood restaurant by id") plus the scope of the payload ("full menu, grouped by category"). The by-id framing implicitly and clearly separates it from the sibling search/list tools that operate over sets.

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 clear from "by id", and the description gives concrete invocation guidance: set includeModifiers to get option groups and warns that this "can be large". It never names an alternative tool explicitly, so it stops short of the 5-level when/when-not routing.

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