AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Update many entries on your AniList list at once

update_list_entries

Idempotent

Batch-update many AniList list entries in one request when they share the same status, score, or progress. Requires entry IDs; an invalid ID rejects the whole batch.

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

TableJSON 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

TableJSON 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.

Addedv0.9.0Sep 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it requires login, explains all-or-nothing atomic semantics, states that a single bad id fails the whole request with no partial application, warns that the error does not identify the bad id, and notes the return summarizes counts rather than full entries. This is exactly the kind of operational detail an agent needs.

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

Conciseness5/5

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

The description is long but every sentence earns its place: purpose, usage guidance, exclusions, input source, failure semantics, and return behavior. It front-loads the primary purpose and sibling differentiation before diving into operational caveats. No filler or redundancy.

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 complex 12-parameter mutation tool with nested objects, the description covers the essential operational surface: when to use it, what it deliberately does not accept, authentication, error behavior, and return shape. The output schema handles return-value details, and the annotations cover idempotency and destructiveness. Nothing critical is left to guesswork.

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, but the description adds genuine semantic value for key parameters: listEntryIds are explicitly list-entry IDs (not media IDs) sourced from get_user_list, score is always on a 0-10 scale regardless of account settings, and progress is only meaningful when entries genuinely share a value. These warnings go beyond the schema's field-name descriptions.

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?

The description opens with a specific verb and resource: 'Apply ONE set of values to many entries on the authenticated user's own AniList list in a single request.' It clearly differentiates the batch tool from its sibling update_list_entry by stating it cannot vary values per entry. No ambiguity about what the tool does.

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?

The description explicitly tells when to use this tool instead of update_list_entry (shared values across entries), and when to use the sibling (different values per entry, or need for customLists/advancedScores). It also names prerequisite context: requires login and expects list entry IDs from get_user_list. This gives the agent a clear decision rule.

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

Deploy Server