AnimeGarden: A Mirror and Aggregator for dmhy BT Releases, With an Open API

The dmhy mirror problem AnimeGarden actually addresses

動漫花園 at share.dmhy.org is a release board where fansub groups post BitTorrent entries for anime episodes. Its pages are built for humans: you browse, you read titles, you click a magnet link. There is no documented public API in the material this review is based on, and no structured filter language. If you want to answer a question like "every release of a given show with simplified-Chinese hardcoded subtitles from a specific fansub group," you either scrape HTML or you keep a browser tab open and refresh it. AnimeGarden positions itself as the third-party mirror and aggregator that fills that gap. The README describes it as "動漫花園 第三方 镜像站 以及 动画 BT 资源聚合站," and the feature list is aimed squarely at developers: an open API, an airing schedule page, advanced search syntax, custom RSS feeds, saved search conditions, and integration with AutoBangumi and AnimeSpace. The audience is therefore narrow and specific. It is for people writing software that consumes anime release data: download automation, notification bots, personal media dashboards, or agent tools that need a searchable catalog. It is not for someone who just wants to watch anime, and it is not a tracker: nothing in the README suggests AnimeGarden hosts torrent files or peers.

How the pipeline is put together: scraper, packages, API, clients

The repository is a TypeScript monorepo. The README points to a packages directory and names several subprojects: the @animegarden/client package, which is the JavaScript and TypeScript wrapper over the HTTP API, and anipar, described as a parser that extracts "structure metadata from resource's title." That parser is the interesting piece. A dmhy release title is a dense string containing the show name, episode number, resolution, subtitle language, subtitle format, codec and fansub group, and anipar is what turns that string into fields a program can filter on. The topics list on the repository includes anitomy, which is the well-known title-parsing library family, and bangumi, which points at the metadata side. The aggregation layer therefore works in three stages: collect release entries from the upstream board, parse each title into structured attributes, and serve the result. The serving surface is where the project spends most of its documentation. There is a REST API under api.animes.garden, an MCP endpoint at the same host under /mcp, generated RSS feeds, an iframe embed, and the npm client. The data flow for a consumer is one-directional: you send filter parameters, you receive release records. Nothing in the README describes a write path, user accounts, or a submission mechanism, so treat the API as read-only. The AirBnB-style advanced search syntax shown in the README, `葬送的芙莉莲 +简体内嵌 字幕组:桜都字幕组 类型:动画`, is the human-facing expression of the same filter fields the API exposes.

Getting data out: REST, MCP, npm client and RSS

The lowest-friction entry point is a single curl. The README gives this exact command: `curl "https://api.animes.garden/resources?page=1&pageSize=10"`. Pagination is explicit through page and pageSize. Interactive OpenAPI documentation lives at animes.garden/docs/api, and the repository carries an examples/api.http file with further request cases. If you are working in JavaScript or TypeScript, install the client with `npm i @animegarden/client` and call it as the README shows: `import { fetchResources } from '@animegarden/client'`, then `await fetchResources()` for the first page, or `await fetchResources({ count: -1, fansub: 'ANi' })` to pull everything matching a filter. The count: -1 convention is worth noticing: it means "all matching resources," which is convenient and also the fastest way to make a long-running request against someone else's server. A constraint the README states plainly: your runtime must provide a global Fetch. If it does not, you polyfill with undici or ofetch. That rules out older Node versions and any environment without a fetch implementation unless you add one. For agent-style tooling there are two more paths. An MCP server is available at `https://api.animes.garden/mcp`, configured in a client with a JSON block containing `"mcpServers": { "animegarden": { "url": "https://api.animes.garden/mcp" } }`. And a skill can be added with `npx skills add https://github.com/yjl9903/AnimeGarden --skill animegarden`. For non-programmatic consumption, the site generates RSS feed URLs from saved filters, and the iframe embed `<iframe src="//animes.garden/iframe?subject=477825" width="100%" height="600" frameborder="0"></iframe>` drops a release list into any page.

Where the mirror model breaks down

The central limitation is architectural, not a bug. AnimeGarden mirrors 動漫花園. It does not own the release data, it does not control the posters, and it cannot guarantee that an entry present today is present tomorrow. The README makes no statement about retention, backfill depth, or what happens when the upstream board is unreachable. If you build a service that treats the API as a system of record, you are building on a copy of a copy. The correct posture is to cache what you fetch and to treat misses as expected. The second limitation is scope: this is anime BT releases from one upstream board plus whatever the aggregator pulls in. The acknowledgements list 蜜柑计划, 萌番组, Bangumi and bangumi-data, but the README does not describe how much of each is ingested or how they are merged, so a consumer cannot tell from the documentation alone which sources back a given query result. Third, the API is a shared public endpoint with no documented authentication or rate limits in the material available here. The `count: -1` option makes it easy to issue an unbounded query; there is nothing in the README that tells you what happens when many clients do that at once. Fourth, and this is the case where it is simply the wrong tool: if you need a tracker, if you need to seed or peer, or if you need guaranteed availability of a specific torrent file, AnimeGarden is not that. It gives you metadata and magnet references. Downloading and seeding are the job of whatever client you point at those references.

AnimeGarden against scraping dmhy yourself

The obvious alternative is to scrape share.dmhy.org directly. The difference in approach is real and cuts both ways. A scraper gives you the raw page and nothing else: you write the HTML parsing, you maintain it when the markup changes, and you write your own title parser to turn a release string into episode, resolution and subtitle fields. AnimeGarden has already done that work in anipar and exposes the result as typed filter options, with a documented FilterOptions type in the client package. The trade-off is control and coupling. A scraper sees exactly what the upstream site sees, including new fields on the day they appear. AnimeGarden sees what its maintainers have chosen to mirror and parse, and your data is only as fresh as the last sync. A second alternative is the npm client versus raw HTTP. The client is a thin wrapper, and the README says so; if you are not in JavaScript, use the REST endpoint or the MCP server and skip the package entirely. A third alternative, for people who only want files on disk, is to skip the API and wire the generated RSS feed into AutoBangumi or AnimeSpace, both of which the README lists as supported integrations. That path needs no code at all, and for most single-user setups it is the right one.

Maintenance cost, release cadence and the AGPL-3.0 boundary

The release history in the material shows v0.5.2 in May 2025, v0.5.3 in March 2026 and v0.5.4 in May 2026, with the last push to main in September 2026. That is a slow, steady cadence rather than a fast-moving one, and the version numbers staying in the 0.5.x range tells you the maintainer has not declared a stable 1.0. Practically, that means you should pin the client version in package.json rather than floating on a caret range, because minor bumps can carry behavior changes while the project is pre-1.0. The heavier maintenance burden is not the npm package; it is the upstream. Any change to dmhy's markup or to the title conventions that fansub groups use can break the scraper or the parser, and those fixes land on the project's schedule, not yours. If your application depends on a field that anipar extracts, budget for the possibility that the extraction changes. On licensing: the project is AGPL-3.0. The practical consequence, stated without legal advice, is that AGPL is a strong copyleft licence with a network clause, so if you modify the code and expose it as a network service, the licence's terms reach that service. Consuming the public API from your own separate program is a different question from copying the source into your program, and the two should not be conflated. If you are embedding the code rather than calling the endpoint, have someone qualified read the licence against your deployment model before you commit.

Who should wire this in, and what to check before you do

The fit is clear for a specific kind of user: someone building a notification bot, a personal media front end, a download automation pipeline, or an agent tool that needs to look up anime releases by structured criteria. The three integration points scale with how much code you want to write. RSS into AutoBangumi or AnimeSpace is zero code. The REST endpoint or @animegarden/client is a few lines. The MCP server or the skills CLI is for agent frameworks. Before committing, check three things. First, confirm that api.animes.garden is reachable and responsive from your deployment network, since the whole design assumes you can call it. Second, confirm your runtime has a global Fetch, or plan the undici or ofetch polyfill the README names. Third, decide what your fallback is when a query returns nothing, because a mirror of an upstream board will have gaps and the documentation does not promise otherwise. If your requirement is archival completeness or guaranteed torrent availability, this project does not claim to provide either, and you should look elsewhere rather than build around it.

Editorial conclusion

Adopt AnimeGarden if you need structured anime release metadata in a program rather than a browser tab: the REST endpoint at api.animes.garden, the MCP server at api.animes.garden/mcp and the @animegarden/client package all serve that purpose, and AutoBangumi or AnimeSpace integration covers the download-automation case. Do not adopt it as a tracker or as a source of long-term archival data, because it mirrors an upstream board it does not own and the README makes no retention guarantee. Verify first that the upstream dmhy site is reachable from your network, that your runtime provides a global Fetch (or that you can polyfill it with undici or ofetch), and that you are willing to accept AGPL-3.0 terms before linking the code into a larger service.

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. yjl9903/AnimeGarden on GitHub