Get a user's activity feed

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and dynamic nature are covered. The description adds valuable context: no type filtering, username resolution via an internal lookup, and the absence of a need for search_user. It does not mention error behavior for unknown users in the main description, but that is documented in the parameter schema, so the added value is solid but not exhaustive.

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 deliver purpose, scope, parameter clarification, and alternative-tool guidance with zero filler. The information is densely packed and front-loaded with the primary purpose before moving to alternatives, making it easy for an agent to quickly grasp the tool's role.

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?

Given the output schema exists to explain return values and the annotations cover safety semantics, the description completes the picture: it states what the tool does, how the username parameter works, pagination context is in the schema, and it names the exact alternatives for nearby use cases. The tool is relatively simple (3 params, flat output), and the description covers all necessary decision points.

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 meaning beyond the schema by explaining that the 'user' parameter accepts an exact username directly (resolved internally) and by contrasting behavior with search_activity's user filter. This enrichment of the user parameter justifies a 4.

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 'List recent AniList activity posts from a specific user' – a specific verb, resource, and scope. It also notes that all activity types are included and no type filter is applied, which differentiates it from sibling search_activity and get_user_recent_activity.

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?

The description explicitly states when to use alternatives: 'Use search_activity instead if you want to restrict to one activity type... or browse without pinning to one user' and 'Use get_user_recent_activity instead if you just want a quick, fixed-size (5-item) recent snapshot.' It also advises that search_user is unnecessary for exact usernames, providing clear decision guidance.

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