AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Update many entries on your AniList list at once

update_list_entries

Idempotent

Apply one shared set of values to many AniList list entries in a single request, such as marking thirty titles completed at once. Saves repeated calls when every entry gets the same update.

Instructions

[Requires login] Apply ONE set of values to many entries on the authenticated user's own AniList list in a single request — e.g. mark thirty titles COMPLETED, or set the same score on a batch. Use this instead of calling update_list_entry in a loop whenever the entries share the values you're writing; use update_list_entry when each entry needs DIFFERENT values (this tool cannot vary them per entry), or when you need to set customLists/advancedScores, which this tool deliberately doesn't accept. Takes list-ENTRY ids (not media ids) — get them from get_user_list. The whole call is all-or-nothing: if any id is unknown or isn't yours, AniList rejects the request and applies NOTHING, so there is never a half-applied batch to clean up — but the error does not say which id was at fault, so re-check the ids against get_user_list. Returns a summary (how many were updated, and their ids), not the full entries.

Input Schema

Name	Required	Description
`notes`	No	New free-text notes, written to every listed entry (per AniList's own schema, capped at 6000 characters).
`score`	No	New score out of 10 (decimals allowed), applied to every listed entry. Always on this scale regardless of the account's configured scoreFormat.
`repeat`	No	New rewatch/reread count (per AniList's own schema, capped at 1000).
`status`	No	New list status, applied to every listed entry.
`private`	No	Hide/unhide every listed entry.
`priority`	No	New list priority (higher = more important; per AniList's own schema, capped at 255).
`progress`	No	New episodes watched / chapters read, applied to every listed entry — only meaningful when they genuinely share a progress value.
`startedAt`	No	New start date for every listed entry.
`completedAt`	No	New completion date for every listed entry.
`listEntryIds`	Yes	The list ENTRY ids to update (not media ids), from get_user_list. Every id must exist and belong to you — one bad id fails the entire call without changing anything.
`progressVolumes`	No	New volumes read (manga only).
`hiddenFromStatusLists`	No	Hide/unhide every listed entry from the public status-grouped list views.

Output Schema

Name	Required	Description	Default
`updated`	Yes	How many entries AniList reported as updated.
`listEntryIds`	Yes	The list-entry ids AniList reported as updated.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.11.0Oct 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / completedAt / properties / year / description
```
Added value: +"Required — omit the whole date to leave it unchanged."
```
- addedInput schema / properties / completedAt / required
```
Added value: +[
+  "year"
+]
```
- addedInput schema / properties / startedAt / properties / year / description
```
Added value: +"Required — omit the whole date to leave it unchanged."
```
- addedInput schema / properties / startedAt / required
```
Added value: +[
+  "year"
+]
```
Addedv0.9.0Sep 27, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond annotations by disclosing the all-or-nothing atomicity contract, the fact that the error omits the offending id, and the recovery procedure (re-check ids against get_user_list). It also states the return shape. Minor gap: it doesn't restate that repeated calls with the same payload are harmless, though annotations already supply idempotentHint.

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-loads the login requirement and the core batch semantics, and every sentence carries decision-relevant information (alternatives, exclusions, id type, failure mode). It is dense but long for a single paragraph; splitting the failure-mode guidance out would improve scanability slightly.

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?

For a 12-parameter nested-object mutation, it covers auth, id provenance, atomicity, excluded fields, alternatives and return summary — everything needed to call it correctly. An output schema exists, so the brief return summary is more than sufficient.

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 earns more by emphasizing that listEntryIds are ENTRY ids not media ids and by flagging that per-entry variation is impossible — a semantic constraint the schema cannot express. It doesn't mention that omitted fields are left unchanged for most params (only the date schemas say this).

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 (apply one set of values), resource (many list entries on the authenticated user's AniList list) and batch scope in one request. The example ('mark thirty titles COMPLETED') makes the operation concrete and immediately distinguishes it from the single-entry sibling.

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

Usage Guidelines5/5

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

Explicit routing: use this instead of update_list_entry in a loop when entries share values; use update_list_entry when values differ per entry or when customLists/advancedScores are needed. It also states the login prerequisite and points to get_user_list as the id source.

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

Deploy Server