List food safety constraints

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description still adds real context by specifying that only 'confirmed' constraints are returned and that the source is the personalized profile, but says nothing about ordering, completeness, or what an empty result means.

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?

One front-loaded sentence with the verb first and no filler; every clause (the four constraint categories, 'confirmed', 'personalized profile') carries information.

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 input params and a low-complexity read, the enumerated categories effectively stand in for the return shape even though no output schema exists. Minor residual gap: it does not say whether results include severity, source, or how exclusions differ structurally from allergies.

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 tool takes zero parameters, so the schema baseline is a 4 and there is nothing for the description to disambiguate or compensate for.

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 concrete verb ('Read') plus an enumerated resource set (allergies, intolerances, dietary restrictions, excluded foods) with the source ('personalized profile'). This clearly separates it from the write-side siblings prepare_upsert_safety_constraint and prepare_delete_safety_constraint, though it never names them or get_food_profile explicitly.

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 only implied: an agent can infer this is the lookup to run before proposing meals or logging intake. There is no explicit statement of when to call it, nor any pointer to the sibling that should be used instead for editing constraints.

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