Skip to main content
Glama
nochinsky

anilist

by nochinsky

search manga

search_manga
Read-onlyIdempotent

Search manga by title, genre, or year to retrieve IDs, chapter and volume counts, and current list entries; present ambiguous matches for the user to choose.

Instructions

Search manga candidates or browse by genre/year. Returns IDs, chapter/volume counts and current list entries. Present ambiguous matches for the user to choose.

Input Schema

NameRequiredDescriptionDefault
pageNo
sortNo
yearNo
genreNo
queryNo
per_pageNo
include_adultNo
exclude_media_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds return-field information and a disambiguation instruction, which is genuine added value. It stays silent on pagination behavior (page/per_page defaults), adult-content filtering, and result-size limits, so it is helpful but not rich.

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?

Three short sentences, front-loaded with the core capability, followed by return contents and the one workflow rule. No filler and nothing repeated from the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does cover the key return fields, which is the most important gap filled. But with 8 undocumented parameters, no required-parameter guidance, and no mention of pagination or adult filtering, an agent still has to guess at invocation details.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description must carry the burden. It only surfaces genre, year and an implied query string; sort, page, per_page, include_adult and exclude_media_ids are entirely unexplained, including their defaults and filtering semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search manga candidates') and names the two modes: query search vs browsing by genre/year. It also discloses what comes back (IDs, chapter/volume counts, current list entries). It does not explicitly distinguish itself from get_manga_details, but 'candidates' implies the pre-detail discovery step.

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

Usage Guidelines3/5

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

The line 'Present ambiguous matches for the user to choose' gives a useful workflow rule, and 'browse by genre/year' implies when the filter mode applies. However, there is no explicit guidance on when to call this vs get_manga_details, nor on combining query with genre/year, nor on when to page through results.

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