AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Log in to AniList

login_anilist

Authorize personal-list and social tools with your AniList account via a one-time OAuth flow; returns an authorization URL to open, approve, and complete access.

Instructions

Authorize the personal-list and social tools with your AniList account (one-time). Prerequisite: register an app at anilist.co/settings/developer with Redirect URL set to http://localhost:8082/callback (the default; override the port via ANILIST_OAUTH_PORT if 8082 is taken — it must match exactly what you register), and set ANILIST_CLIENT_ID + ANILIST_CLIENT_SECRET in the server env. Calling this returns an authorization URL: open it, log in, and click Approve. If your browser genuinely runs on the same machine as this server, login then completes automatically; otherwise copy the URL you land on and pass it to submit_anilist_redirect. auto_capture in the response is NOT a reliable detector of that — it only reflects whether this server process could bind its own localhost listener, which typically succeeds even when the server runs remotely (SSH/headless) and the browser can never reach it; you (or the user) know the actual machine layout, the response doesn't.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`auto_capture`	Yes	Whether this server process could bind a local callback listener — NOT whether the browser opening authorize_url is actually on the same machine. A remote/SSH server can still bind its own loopback port successfully and read `true` here even though that browser's redirect can never reach it.
`instructions`	Yes
`redirect_uri`	Yes	The exact localhost callback URI this login attempt used (port from ANILIST_OAUTH_PORT, default 8082) — must exactly match the Redirect URL registered for your AniList app, or the token exchange fails.
`authorize_url`	Yes	The AniList OAuth authorization URL — open it in a browser and click Approve.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.11.0Oct 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed3 schema fields changedv0.7.1Aug 1, 2026

addedOutput schema / properties / authorize_url / description

Added value: +"The AniList OAuth authorization URL — open it in a browser and click Approve."

addedOutput schema / properties / auto_capture / description

Added value: +"Whether this server process could bind a local callback listener — NOT whether the browser opening authorize_url is actually on the same machine. A remote/SSH server can still bind its own loopback port successfully and read `true` here even though that browser's redirect can never reach it."

addedOutput schema / properties / redirect_uri / description

Added value: +"The exact localhost callback URI this login attempt used (port from ANILIST_OAUTH_PORT, default 8082) — must exactly match the Redirect URL registered for your AniList app, or the token exchange fails."

Addedv0.2.0Jul 21, 2026
Removedv0.2.0Jul 21, 2026
First observedv0.1.5Jul 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond annotations: it discloses the auth flow, the external dependency (browser/AniList), required env configuration, and a non-obvious caveat that auto_capture is not a reliable remote/headless detector. That caveat is exactly the kind of behavioral insight annotations can't express.

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 purpose then prerequisites then flow. The auto_capture caveat is long and slightly dense but carries real value; a small trim would improve it without losing meaning.

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?

Given an output schema exists, the description needn't enumerate return fields, yet it still explains the key response element (authorization URL, auto_capture). The full multi-step flow is covered so an agent can act correctly.

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?

Zero parameters, so the baseline is 4. The description usefully documents config inputs (ANILIST_CLIENT_ID, ANILIST_CLIENT_SECRET, ANILIST_OAUTH_PORT) that affect behavior, though these aren't schema parameters.

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?

Specific verb and resource: 'Authorize the personal-list and social tools with your AniList account (one-time)'. It is clearly distinguishable from sibling read tools and names submit_anilist_redirect as the follow-up path.

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 when-to-use (one-time authorization for personal-list/social tools), detailed prerequisites (developer app, exact Redirect URL, env vars), and a named alternative path via submit_anilist_redirect with the condition that selects it.

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

Deploy Server