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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial behavior beyond them: required scopes/plan, deterministic ordering, the sponsored perk being pinned to page one with sponsored: true, the null-on-last-page cursor contract, and that total counts every perk passing the filters. Those are exactly the operational traits an agent needs before calling.

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?

The first sentence is an extremely long run-on that chains a dozen returned fields together, burying the pagination and ordering behavior mid-sentence. The filters/paging sentence is tighter, but the whole thing would benefit from being broken into purpose, filters, paging, and auth blocks. Little is wasted, but the structure is hard to scan.

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 output schema, the description appropriately documents the return shape, including the sponsored flag, total count, and cursor behavior. It also covers auth prerequisites and filter semantics. The remaining gaps are the unenumerated kind/availability values and the cursor-vs-nextCursor naming mismatch.

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 carries the burden and does explain q (matches name, tagline or vendor words), limit bounds/default, and cursor semantics. But it never enumerates the kind or availability enum values (saas_deal, startup_program, free_tier, etc.), and it refers to 'nextCursor' while the input parameter is named 'cursor', which can mislead an agent assembling the call.

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 makes clear this is a paginated listing of the getfund perks catalog in list order, and enumerates the fields each perk carries. It is distinguishable from siblings like getfund_programs and getfund_search_programs because it names the 'perks' resource explicitly. The verb, however, is oblique ('Perks of the getfund catalog a page at a time') rather than a crisp 'Lists perks...'.

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?

It gives usable operating context: filters (category, kind, q, availability), a limit range with default, and cursor-based paging with 'null on the last page'. It also states prerequisites ('Needs tracker:read and the Autopilot plan'), which is real when-to-use guidance. It stops short of naming an alternative tool or saying when-not to use this one, though no sibling appears to duplicate this listing.

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