AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Get your AniList notifications

get_notifications

Fetch and filter the authenticated user's AniList notifications. Includes new episodes, likes, replies, mentions, followers, thread activity, data updates with pagination and optional mark-as-read.

Instructions

[Requires login] Get the authenticated user's AniList notifications: new episodes airing, activity likes/replies/mentions, new followers, thread replies/likes, and media/staff/character data-submission updates. Every item has id, type and a human-readable context/contexts string; the rest of the fields depend on type (e.g. an AIRING item includes media/episode, a FOLLOWING item includes user, an ACTIVITY_MESSAGE item includes message.message — the actual DM text is nested one level inside message).

Input Schema

Name	Required	Description
`page`	No	Page number for pagination. AniList's paginated connections (search results, a title's characters/staff/reviews, activity feeds, forum comments) reject a page whose page × perPage exceeds ~5000 entries with an upstream error, so paging that deep fails rather than returning more results.
`perPage`	No	Results per page (max 50, AniList's own ceiling — it silently clamps anything higher).
`type_in`	No	Restrict to these notification types. Omit to get every type. This only filters what's returned here — whether a type is generated at all is controlled separately by the account's own notificationOptions (update_user); a type disabled there simply never appears, regardless of this filter.
`markAsRead`	No	Set true to also reset AniList's unread-notification badge count to 0, as a side effect of this call (the same effect as opening the notifications page on the site). Defaults to false so a routine check doesn't clear the badge.

Output Schema

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.0Oct 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / type_in / minItems
```
Added value: +1
```
Changed4 schema fields changedv0.9.0Sep 27, 2026
- changedInput schema / properties / perPage / description
```
Previous value: -"Results per page (max 25)."New value: +"Results per page (max 50, AniList's own ceiling — it silently clamps anything higher)."
```
- changedInput schema / properties / perPage / maximum
```
Previous value: -25New value: +50
```
- removedOutput schema / properties / results / properties / pageInfo / properties / hasNextPage / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / properties / pageInfo / properties / hasNextPage / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```

Changed12 schema fields changedv0.7.1Aug 1, 2026

changedInput schema / properties / page / description

Previous value: -"Page number for pagination."New value: +"Page number for pagination. AniList's paginated connections (search results, a title's characters/staff/reviews, activity feeds, forum comments) reject a page whose page × perPage exceeds ~5000 entries with an upstream error, so paging that deep fails rather than returning more results."

addedInput schema / properties / perPage / exclusiveMinimum
```
Added value: +0
```
removedInput schema / properties / perPage / minimum
```
Removed value: -1
```

changedInput schema / properties / type_in / description

Previous value: -"Restrict to these notification types. Omit to get every type."New value: +"Restrict to these notification types. Omit to get every type. This only filters what's returned here — whether a type is generated at all is controlled separately by the account's own notificationOptions (update_user); a type disabled there simply never appears, regardless of this filter."

addedOutput schema / properties / results / properties / notifications / items / properties / id / exclusiveMinimum
```
Added value: +0
```
changedOutput schema / properties / results / properties / notifications / items / properties / id / maximum
```
Previous value: -9007199254740991New value: +2147483647
```
removedOutput schema / properties / results / properties / notifications / items / properties / id / minimum
```
Removed value: --9007199254740991
```

addedOutput schema / properties / results / properties / pageInfo / description

Added value: +"Whether another page exists — this query only ever requests hasNextPage, not total/currentPage/lastPage (unlike some sibling paginated tools)."

removedOutput schema / properties / results / properties / pageInfo / properties / currentPage

Removed value: -{
-  "anyOf": [
-    {
-      "maximum": 9007199254740991,
-      "minimum": -9007199254740991,
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

removedOutput schema / properties / results / properties / pageInfo / properties / lastPage

Removed value: -{
-  "anyOf": [
-    {
-      "maximum": 9007199254740991,
-      "minimum": -9007199254740991,
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "Not currently accurate (a known AniList performance limitation) — use `hasNextPage` instead to decide whether to fetch another page."
-}

removedOutput schema / properties / results / properties / pageInfo / properties / perPage

Removed value: -{
-  "anyOf": [
-    {
-      "maximum": 9007199254740991,
-      "minimum": -9007199254740991,
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

removedOutput schema / properties / results / properties / pageInfo / properties / total

Removed value: -{
-  "anyOf": [
-    {
-      "maximum": 9007199254740991,
-      "minimum": -9007199254740991,
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "Not currently accurate (a known AniList performance limitation) — don't rely on it to decide whether to fetch more pages."
-}

Changed1 schema field changedv0.4.0Jul 28, 2026

addedOutput schema / properties / results / properties / notifications / items / description

Added value: +"Only `id` is guaranteed here — the real object has more fields, but their shape depends on which variant of an underlying union type this is (e.g. which activity type), so only the field common to every variant is declared."

Addedv0.2.0Jul 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Critically, it discloses the non-obvious side effect that markAsRead clears the unread badge, which explains why readOnlyHint is false despite the 'Get' framing. It also documents that returned fields vary by notification type, including the subtle nesting of the DM text inside message.message — real behavioral detail beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the auth requirement and core purpose, then a dense but useful second sentence on item shape. Slightly long and parenthetical-heavy, but every clause conveys information an agent would otherwise have to discover empirically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still adds the essential insight that fields depend on type, which is exactly the kind of variability a schema alone would obscure. Auth requirement, side-effect behavior, and filter interactions are all accounted for.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds genuine value by explaining the type-dependent shape of returned items (AIRING includes media/episode, FOLLOWING includes user, ACTIVITY_MESSAGE nests text). It doesn't restate page/perPage/markAsRead semantics, which the schema already carries well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the authenticated user's AniList notifications') and enumerates the concrete notification categories covered, so an agent immediately knows the scope. No sibling tool overlaps this function, and the description makes that distinct role obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The '[Requires login]' prefix establishes the auth precondition, and the type_in description explains the interaction with the account's notificationOptions setting. It does not explicitly say when to prefer or avoid this tool, but with no close sibling alternative there is nothing to disambiguate against.

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

Deploy Server