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

Adds significant behavioral context beyond the annotations: menus are immediately public, ownership requires the claim link, unclaimed menus are deleted after expiration, and allergen labelling is unsupported. These are non-obvious side effects and limitations that the annotations (readOnlyHint=false, openWorldHint=true) do not convey.

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 tightly written sentences with no filler. The first sentence states purpose and return values; the second clarifies visibility; the third covers the critical claim-link workflow and a limitation. All content earns its place, and key information is 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?

Since there is no output schema, the description appropriately lists the return values and explains the essential follow-up action (showing the claim link). It covers the main workflow but omits some specifics such as the claim-link validity period and error behavior, though the rich input schema handles structural validation.

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 the schema already documents every field. The description goes beyond this by instructing how to handle allergen notes within dish descriptions, which is parameter-level guidance not present in the schema. It does not restate existing schema details.

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: 'Creates a live, public digital restaurant menu on topfood.app from structured menu data' and lists concrete return values (public menu URL, QR code, claim link). This clearly distinguishes it from the only sibling tool, report_problem, which serves a different purpose.

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 clear context for when to use the tool — publishing a menu from structured data — and includes direct agent guidance ('always show the user the claim link'). It does not explicitly name exclusions or alternatives, but the only sibling (report_problem) is unrelated, so no competing use case is missed.

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