list_notifications

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the return shape (thread objects with subject, repository, reason, updated_at), the pagination cap (50 instead of the usual 100), and the all parameter's effect. Does not mention error responses or rate limits, but covers the key behavioral aspects for a list endpoint.

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 plus a docs link, front-loaded with the main purpose. Every sentence earns its place, covering return type, fields, all parameter, and pagination nuance without redundancy.

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 list endpoint with no output schema, the description provides enough context: return type and fields, pagination behavior, parameter semantics for all, and a link to official docs. The schema covers the remaining parameters clearly.

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 83%, so the baseline is 3. The description adds value beyond the schema by explaining the per_page cap's reason ('GitHub caps this endpoint at 50') and the practical use of all=true. It does not mention participating, but the schema already describes it, so no 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 opens with a specific verb+resource ('List notifications for the authenticated user') and clearly differentiates scope (authenticated user's notifications). It also previews the return type (array of thread objects), which leaves no ambiguity about the tool's function.

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?

Provides clear context on use: explains the all parameter for including read notifications, and pagination via page/per_page with the endpoint-specific cap of 50. Lacks explicit when-not-to-use alternatives, but no direct sibling tool exists for notifications, so the context is sufficient.

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