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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does, disclosing default ordering (newest first), the time zone of the timestamp (branch time zone), and the exact fields returned. It does not mention that results are capped at 50 with no pagination cursor, which is the one remaining behavioral gap.

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 dense sentence with the resource and ordering front-loaded, and the trailing colon-list of returned fields earns its place given there is no output schema. Slightly compressed phrasing ('customer display name and reference, branch and program') but no 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?

For a three-optional-parameter read tool with no output schema, the field enumeration partially substitutes for a return description. However, an agent still cannot tell from the description how type/branch_id filtering interacts, whether the 50-row cap means data can be silently truncated, or whether repeated calls return stable results across the feed 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 description coverage is 0%, so the description must carry the burden, and it largely does not: 'limit' and 'branch_id' are never referenced as filters, and the enum values are only obliquely implied by the words 'stamps, redemptions and corrections'. It adds a little semantic mapping (corrections ≈ reversal) but nothing about how the parameters shape the result.

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?

Names a specific resource (the newest stamps, redemptions and corrections) and its ordering, so an agent can tell it apart from aggregate siblings like get_analytics or get_shop_summary. It is a noun phrase rather than a verb+resource statement, but the intent is unambiguous.

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?

No when-to-use guidance and no named alternatives; the agent is left to infer that this is the raw recent-activity feed rather than the summarized/analytics tools. Nothing states whether the filters are combinable or what happens with no filters at all.

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