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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: the feed is specifically populated by sends with 'feed' or 'showInFeed', and pagination requires passing nextCursor back as cursor. No contradiction with annotations.

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 sentences, each earning its place: what the tool reads, what it excludes, and how pagination works. The most important scope 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?

For a read-only feed tool with 7 parameters, high schema coverage, and annotations covering safety, the description is mostly complete. It identifies the resource type, the relevant send modes, and pagination flow. It does not describe output ordering, but no output schema is declared and this is a minor gap for a list-type operation.

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%, so the baseline is 3. The description adds useful parameter-related context by explaining the pagination contract ('Passing nextCursor back as cursor') and clarifying the feed's relationship to sends, which goes slightly beyond the schema's individual field descriptions.

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 names the specific resource ('one end user's in-app notification feed'), the exact verb ('Read'), and the endpoint (GET /notifications). It also clearly differentiates this from delivery status, which is handled by get_send_status.

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 states exactly when to use this tool: to read in-app feed entries from sends with 'feed' or 'showInFeed'. It explicitly points to get_send_status as the alternative for delivery status, giving the agent clear routing guidance.

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