AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Search users

search_user

Read-only

Search AniList for users by username or partial name and return their user IDs for use with profile, stats, list, and follow tools.

Instructions

Search AniList for users by username. Returns AniList user IDs to use with get_user_profile/get_full_user_info (profile), get_user_stats (statistics), get_user_list (their public list), or toggle_follow_user.

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.
`term`	Yes	Username (or part of it) to search for.
`perPage`	No	Results per page (max 50, AniList's own ceiling — it silently clamps anything higher).
`includeDescription`	No	Also fetch each result's full bio (`about`). Kept off by default — a bio can run to several thousand characters, and always including it would burn tokens on text you may not need; use get_user_profile/get_full_user_info for a single entry's full bio instead.

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
```

changedInput schema / properties / includeDescription / description

Previous value: -"Also fetch each result's full bio (`description`). Kept off by default — a bio can run to several thousand characters, and always including it would burn tokens on text you may not need; use get_user_profile/get_full_user_info for a single entry's full bio instead."New value: +"Also fetch each result's full bio (`about`). Kept off by default — a bio can run to several thousand characters, and always including it would burn tokens on text you may not need; use get_user_profile/get_full_user_info for a single entry's full bio instead."

Changed5 schema fields changedv0.9.0Sep 27, 2026

addedInput schema / properties / includeDescription

Added value: +{
+  "default": false,
+  "description": "Also fetch each result's full bio (`description`). Kept off by default — a bio can run to several thousand characters, and always including it would burn tokens on text you may not need; use get_user_profile/get_full_user_info for a single entry's full bio instead.",
+  "type": "boolean"
+}

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"
+]
```

Changed6 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
```
- addedOutput schema / properties / results / properties / users / items / properties / id / exclusiveMinimum
```
Added value: +0
```
- changedOutput schema / properties / results / properties / users / items / properties / id / maximum
```
Previous value: -9007199254740991New value: +2147483647
```
- removedOutput schema / properties / results / properties / users / items / properties / id / minimum
```
Removed value: --9007199254740991
```

Changed1 schema field changedv0.4.0Jul 28, 2026

addedOutput schema / properties / results / properties / users / 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.3.0Jul 26, 2026
Removedv0.2.0Jul 21, 2026
First observedv0.1.5Jul 21, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-lookup behavior are covered without the description. The description adds the useful fact that results are IDs usable elsewhere, but says nothing about matching semantics (partial vs exact username), empty-result behavior, or result count — details the schema only partly touches via perPage.

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?

Two sentences, front-loaded with the core action, then the return-value/consumer mapping. No filler, no restatement of the title, and every clause carries new information.

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, annotations cover the read-only/open-world profile, and the schema fully documents all four parameters. The description supplies the one thing none of those structured fields can: which sibling tools consume the returned IDs. Nothing an agent needs to invoke this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter docs are unusually rich (page × perPage ceiling, perPage clamping at 50, includeDescription token trade-off). The description adds nothing about parameters, so the baseline 3 applies — the schema, not the description, is doing all the parameter work.

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 ("Search AniList for users by username") and immediately says what comes back: AniList user IDs. It distinguishes itself from get_user_profile/get_user_stats/get_user_list/toggle_follow_user by positioning itself as the ID-resolution step that feeds those siblings, which is exactly the distinction an agent needs.

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 description explicitly routes the agent: use this to obtain user IDs, then pass them to one of four named downstream tools, which is a concrete when-to-use rule. It lacks an explicit negative case (e.g. "if you already have a user ID, call get_user_profile directly"), so it falls one step short of full 5-level guidance.

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

Deploy Server