AniList MCP Server

Overview Schema Source Related Servers Discussions Admin

Search characters

search_character

Read-only

Locate anime characters by name on AniList, returning IDs to use for detailed lookups. Optionally include full character bios in results.

Instructions

Search AniList for characters by name. Returns AniList IDs to use with get_character. Each result's bio (description) is omitted unless you set includeDescription.

Input Schema

TableJSON 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	Character name (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 (`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_character for a single entry's full bio instead.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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

Changed1 schema field changedv0.8.0Aug 17, 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_character for a single entry's full bio instead.",
+  "type": "boolean"
+}

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

Changed1 schema field changedv0.4.0Jul 28, 2026

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

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark this as read-only and open-world, so the safety profile is covered. The description adds valuable behavioral context beyond that: results omit bios by default, and the returned values are AniList IDs meant for downstream use with get_character. This is genuinely useful for invoking the tool correctly.

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, zero filler, and the core purpose and primary behavioral caveat are both front-loaded. Every clause earns its place, and the description is easy to parse in a tool list.

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?

The tool is a simple paginated search with a rich input schema, an output schema, and read-only annotations. The description covers the essential workflow (search → get_character), the notable token-saving default, and nothing important is missing for correct invocation.

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 every parameter already has a detailed, self-explanatory description. The tool-level description largely repeats the includeDescription point already present in the schema, so it adds little semantic value beyond what the schema provides. Baseline 3 is appropriate.

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 states a specific verb and resource: 'Search AniList for characters by name.' It also clarifies the tool's role in a workflow by saying it 'Returns AniList IDs to use with get_character,' which distinguishes it from the get_character and other search siblings. The scope is unambiguous.

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 makes the search-vs-fetch distinction explicit by framing the output as IDs to feed into get_character, and it tells the agent when to set includeDescription. It does not explicitly contrast with sibling search_staff, search_media, etc., but the resource-specific phrasing makes the intended use clear.

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

Deploy Server