Anime Garden MCP for anime torrent discovery.
Scored across 1 tool
There is only one tool, so there is no risk of selecting the wrong tool or confusing overlapping purposes. Its purpose—searching anime resources with filters—is clear from the name and description.
The single tool uses a clear snake_case verb_noun pattern: search_resources. With only one tool, no naming inconsistency can arise.
A single search tool can cover many query patterns via rich filters, but the server surface is quite thin for an anime resource domain. It sits at the borderline where one tool may be sufficient for a focused search API but feels limited for broader browsing workflows.
The tool supports searching and filtering resources but appears to lack companion operations such as retrieving resource details, listing fansubs or subjects, fetching download links, or paginating results explicitly. These gaps would likely force agents to rely solely on search results without lifecycle or detail coverage.
Search filter behavior:
Different conditions are combined with AND.
Within fansubs/publishers/types/subjects/include/exclude, values are OR.
search has higher priority than include.
keywords uses AND (all keywords must be present), exclude uses AND (all excluded words must not be present). Recommended search patterns:
Latest episode releases: {"types":["动画"]}
Specific show + quality + codec: {"search":["Re:Zero"],"keywords":["1080p","HEVC"]}
Fansub-focused browsing: {"fansubs":["LoliHouse"],"types":["动画"],"after":"2026-02-01"}
Subject tracking with cleanup terms: {"subjects":[123456],"exclude":["合集","NCOP","NCED"]}
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Lower time bound (inclusive). Keep resources with createdAt >= after. Accepts date string or timestamp. | |
| types | No | Resource categories. Match ANY value (OR). Common values: "动画", "合集". | |
| before | No | Upper time bound (inclusive). Keep resources with createdAt <= before. Accepts date string or timestamp. | |
| search | No | Full-text query terms (tokenized search). If provided, it takes precedence over include. | |
| exclude | No | Blocked title keywords. Exclude resources containing ANY value. | |
| fansubs | No | Fansub group names. Match ANY value (OR). Example: ["喵萌奶茶屋", "LoliHouse"]. | |
| include | No | Title-contains terms. Match ANY value (OR). Only effective when search is not provided. | |
| keywords | No | Required title keywords. Title must contain ALL values (AND). | |
| subjects | No | Bangumi subject IDs. Match ANY value (OR). | |
| publishers | No | Publisher names. Match ANY value (OR). Combined with fansubs in OR logic within this group. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the non-obvious filter semantics: cross-group AND, intra-group OR, AND for keywords/exclude, and search's precedence over include. However it says nothing about result limits, sorting, pagination, or authentication, and with no output schema the return shape is entirely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The AND/OR combination rules are front-loaded before the examples, and every line earns its place. The bullet-plus-numbered-list formatting is scannable, though the mixed prose/list style is slightly heavier than necessary for the amount of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Ten optional parameters and a fairly complex filtering model are well covered by the combination rules and examples. The gap is the missing output information: with no output schema and no annotations, the description never says what a result looks like, whether results are paginated, or how many are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds value by showing how parameters combine across groups and by supplying realistic example payloads with concrete values (fansub names, type values, date formats). The precedence rule it repeats is already in the schema, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search filter behavior' and the examples make it clear this is a resource search, but it never states the specific verb+resource+scope in prose — that lives only in the title. An agent reading only the description would infer a filtered search over aggregated anime torrent resources, but it is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Four concrete query patterns ('latest episode releases', 'specific show + quality + codec', 'fansub-focused browsing', 'subject tracking with cleanup') give clear guidance on how to combine filters for common intents. There are no siblings and no explicit when-not-to-use case, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_resourcesAniList MCP — wraps AniList GraphQL API (free, no auth)
Kitsu MCP — anime + manga catalogue (JSON:API).
AnimeQuotes MCP — wraps animechan.io (free, no auth)
Jikan MCP — wraps the Jikan v4 API (anime/manga data, free, no auth)
Add one secure layer between your agents and this server.