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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context the annotations do not: only 'active' codes are returned and results follow the Koddeo page order with boosted and Premium codes first. It stops short of disclosing pagination or how many codes come back by default.

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 front-loaded sentence with zero filler; the scope and ordering rule are stated up front.

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 simple read-only list tool this covers purpose and ordering, but leaves the result-size behavior unexplained: an agent cannot tell from the description that it gets only 5 codes by default or that 20 is the cap. That is the one material gap given there is no output schema.

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 50%: slug is well documented, but limit (default 5, max 20) has no description in the schema and is never mentioned in the description. The ordering sentence adds nothing about the limit parameter, so the description does not compensate for the coverage gap.

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 gives a specific verb (List) and resource (active community referral codes for one brand) plus the ordering semantics. It distinguishes itself implicitly from list_my_codes by scoping to 'one brand', but never names a sibling or says how it differs from list_my_codes/get_my_account.

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: use it when you want a brand's codes. There is no explicit 'use this when', no exclusions, and no pointer to alternatives such as list_my_codes for the caller's own codes. The slug schema field does point to search_companies, which partially routes the agent.

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