English manga release dates, volumes, ISBNs and new licenses. Read only, no sign in.
Scored across 8 tools
Each tool targets a distinct retrieval need: search, series detail, volume detail, release calendar, statistics, ISBN lookup, and anime-to-manga mapping. The main overlap is between get_new_licenses and get_releases, but their scopes (first English edition by year vs. any volume in a short date window) are clear enough from the descriptions.
All names use snake_case and most follow a predictable verb_noun pattern such as get_series, search_series, and lookup_isbn. The phrase-style where_anime_ends and the repeated get_ prefix introduce minor inconsistency, but the convention remains readable.
Eight tools is well-scoped for a manga information service, with each tool covering a distinct query type. There is no excessive surface area or thin single-tool coverage.
The surface covers search, series and volume detail, release calendars, new licenses, analytics, ISBN lookup, and anime-to-manga mapping, which is strong for the domain. Minor gaps such as publisher- or creator-centric browsing are possible but not critical for the core use cases.
Manga series whose first English edition comes out in a year: English publisher, first volume, its date and status in Japan, in date order. A series counts in the year its first English book holding volume 1 comes out. The date is that book's release date, not the day a license was announced. Defaults to this year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | The year, like 2026. Default this year (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered; the description adds real value on top by disclosing the sort order (date order), the default year, and the counting rule (a series counts in the year its first English volume-1 book ships). It does not mention result size, pagination, or truncation, which keeps it short of a 5.
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?
Three tight sentences, front-loaded with the returned content before the counting caveats. The 'defaults to this year' clause duplicates the schema description, a small redundancy in an otherwise waste-free passage.
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?
There is no output schema, and the description compensates by listing the fields returned and their ordering, which is exactly what an agent needs. Given a one-parameter, read-only tool, only the absence of any result-count or pagination note keeps it from being complete.
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 coverage is 100% and the single year parameter is fully documented with its default, so the baseline is 3. The description does add interpretive meaning — that the year is keyed to the first English volume's release, not the license announcement date — but that is largely a restatement of the same scoping rule.
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 gives a specific verb-and-resource definition: manga series whose first English edition releases in a given year, with the returned fields enumerated (English publisher, first volume, its date, status in Japan). It is clearly narrower than a general releases or series lookup, though it never names a sibling such as get_releases to draw the boundary explicitly.
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?
Usage is only implied — an agent infers you call it when you want licenses grouped by year, and the default of the current year is stated. There is no explicit when-not or pointer to get_releases/search_series for the adjacent queries, which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The English manga volumes Mangainfo lists for a window of dates, at most 62 days: series, volume, edition, publisher, ISBN and date. A volume dated only to a month shows when the month overlaps the window. Defaults to the next 7 days from today (UTC).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last day, YYYY-MM-DD. Default 6 days after from. | |
| from | No | First day, YYYY-MM-DD. Default today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered; the description adds real value beyond that with the 62-day maximum window, the UTC-based default range, and the month-precision overlap rule for volumes dated only to a month. It does not discuss pagination or result-size limits, keeping it short of a 5.
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?
Two sentences, both dense with actionable specifics: scope and returned fields first, then defaults and the edge-case rule. No filler or restated title.
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?
With no output schema, the description compensates by enumerating the returned fields and explaining the month-only volume behavior. The 62-day limit and defaults round out what an agent needs, though result ordering and volume of results are unstated.
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 coverage is 100%, so both date parameters and their defaults are already documented in the schema. The description reinforces the default window and adds the 62-day cap constraint, which is meaningful but marginal beyond the schema baseline.
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?
States a specific verb and resource ('The English manga volumes Mangainfo lists') plus the entity fields returned (series, volume, edition, publisher, ISBN, date). This clearly distinguishes it from siblings like get_new_licenses or get_series_volumes, which cover different resource types.
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?
Gives a concrete default window ('next 7 days from today (UTC)') and a hard cap, which implies typical usage, but never states when to prefer this over siblings such as get_new_licenses or get_series_volumes, nor any exclusion conditions. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistics of English manga for a year, or one month of it: new English volumes released per month and per publisher, the median and average months from the Japanese release to the first English edition per publisher, the fastest and slowest series, and the series that started and finished in English. A volume counts once, in the month of its first English edition. Defaults to the latest year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | The year, like 2026. Default the latest year with a report. | |
| month | No | A month from 1 to 12 for the figures of one month. Leave out for the whole year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior, and the description adds meaningful aggregation semantics beyond them: a volume counts once in the month of its first English edition, and the default is the latest year with a report. These are important behavioral rules for interpreting results, though no return format or pagination details are given.
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 description is a single front-loaded sentence that begins with the tool's purpose and then enumerates the report contents without filler. It is dense but every clause contributes to understanding what the report includes, though readability could be slightly improved with sentence breaks.
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?
With no output schema, the description carries the burden of explaining return content, and it does so by enumerating the statistics included. Parameters are fully covered by the schema, and annotations cover safety, leaving only minor gaps around exact response structure or formatting.
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 both parameters are already documented in the schema. The description reinforces the year/month behavior and the default year, but adds little syntax or format detail beyond what the schema provides, making 3 the appropriate baseline.
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 states a specific resource and output: aggregated English manga release statistics, including per-publisher volume counts, translation lag, fastest/slowest series, and completed series. It is clear what the tool does, though it does not explicitly name sibling tools like get_releases or get_new_licenses to distinguish when to use this report instead.
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?
Usage is implied through the year/month parameters and the note that it defaults to the latest year, but there is no explicit guidance on when to choose this tool versus siblings such as get_releases or get_series. The description tells the agent what it returns, not when it should be selected over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One manga series on Mangainfo: its titles, status in Japan and in English, volumes out in Japan and in English, the latest and the next English volume with date and precision, creators, English publishers and the page to cite. Takes a slug such as "blue-lock" or a title.
| Name | Required | Description | Default |
|---|---|---|---|
| series | Yes | The slug from a Mangainfo address (mangainfo.com/series/blue-lock is blue-lock) or a title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent lookup, so the description does not need to repeat safety traits. It adds useful behavioral context by enumerating the series details returned, which matters because there is no output schema. It does not cover error behavior such as missing or ambiguous matches, but the main output expectations are clear.
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 description is front-loaded with the core purpose and then lists the returned fields efficiently in one sentence. It is dense but not padded, though the long field list slightly reduces readability.
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?
For a simple one-parameter read-only lookup, the description is largely complete: it names the resource, accepted identifier forms, and returned data. The main missing context is sibling differentiation, especially when to prefer search_series or get_series_volumes.
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 parameter semantics are already fully documented in the schema. The description repeats that the input can be a slug like "blue-lock" or a title, adding little beyond the existing parameter description. Baseline 3 is appropriate.
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 states a specific resource and scope: one manga series on Mangainfo, with the exact data fields it returns. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as search_series or get_series_volumes.
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?
The description explains the accepted input forms (slug or title) but gives no explicit when-to-use guidance or alternatives. It leaves the agent to infer that search_series should be used for discovery and get_series for retrieving a known series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Japanese volume of a manga series with the chapters it holds and its English editions on Mangainfo: label, format, publisher, ISBN, release date with precision and the volume page. Takes a slug such as "blue-lock" or a title.
| Name | Required | Description | Default |
|---|---|---|---|
| series | Yes | The slug from a Mangainfo address (mangainfo.com/series/blue-lock is blue-lock) or a title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description adds real content beyond them: it enumerates the returned fields (label, format, publisher, ISBN, release date with precision, volume page) so the agent knows what data comes back for a call. It does not state behavior when the slug is unknown or a title is ambiguous, which is the main remaining behavioral gap.
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?
A single dense sentence with no filler, and the core resource is front-loaded. The leading noun phrase is slightly awkward for a verb-first action, but nothing is wasted or buried.
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?
There is no output schema, so the description carries the return-value burden, and it does so by listing the volume-level fields returned. For a single-parameter read-only list tool this is largely sufficient, with only title-resolution and result-size behavior left unaddressed.
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 coverage is 100% and the schema's own property description already gives the slug-from-URL rule with the same 'blue-lock' example. The description repeats that information plus 'or a title', which adds slight clarity about title fallback but no new format or resolution semantics.
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 names a specific resource and its scope: Japanese volumes of a manga series, the chapters each holds, and its English editions, with named fields. It is clear what the tool returns and how it differs from get_series (which presumably describes the series itself), though the sibling differentiation is left implicit.
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?
The only usage-like sentence, 'Takes a slug such as "blue-lock" or a title,' describes the argument rather than when to call this tool. There is no guidance on when to prefer it over get_series, search_series, or lookup_isbn, and no exclusions or preconditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the manga volume with an ISBN-13 or ISBN-10: an English edition or the Japanese original. Returns the series, the volume, the English edition with its date and every other English edition of that volume.
| Name | Required | Description | Default |
|---|---|---|---|
| isbn | Yes | An ISBN-13 or ISBN-10, with or without hyphens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description correctly focuses on behavior it can add: what the call returns (series, volume, English edition with date, and every other English edition). That return-content disclosure is meaningful given no output schema exists.
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?
A single front-loaded sentence with no filler: identifier first, then the accepted forms, then the return scope. Nothing is wasted.
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?
For a one-parameter lookup with full schema coverage, the description covers input forms and summarizes the returned data, which compensates for the missing output schema. It could be slightly fuller on what happens for an ISBN that matches no volume, but nothing essential is absent.
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 coverage is 100% and the schema already documents hyphens and both ISBN forms, so the baseline is 3. The description adds that the ISBN may refer to either an English edition or the Japanese original, which is a semantic detail the schema does not capture.
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?
States a specific verb (find) and resource (manga volume) scoped by an identifier (ISBN-13/ISBN-10), which is clearly distinct from sibling names like search_series or get_series_volumes. It doesn't explicitly contrast itself against those siblings, so it stops short of a 5.
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?
The phrase 'an English edition or the Japanese original' hints at when the identifier form matters, but there is no explicit instruction on when to choose this tool over get_series_volumes or search_series. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find manga series on Mangainfo by any title: English, romaji, Japanese or another name. Returns up to 20 series per page, an exact title first, each with its slug, how many volumes are out in English and in Japan, and the next English volume with its date.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of results, 20 per page. Default 1. | |
| query | Yes | A title or part of one, in English, romaji or Japanese. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent safety profile, and the description adds genuinely useful behavior: 20 results per page, exact-title-first ranking, and the specific fields returned (slug, English/Japan volume counts, next English volume and date). Only the empty-result case is left unaddressed.
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?
Two dense sentences with zero filler; the searchable-by-title capability leads and the return contract follows, so the agent gets scope and output shape immediately.
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?
With no output schema, the description carries the return-value burden and does so well by enumerating the fields. It is nearly complete for a simple two-parameter search; only no-results behavior and whether pages beyond the last error or return empty are unstated.
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 coverage is 100%, so both parameters are already documented, including the 20-per-page default. The description reinforces the multilingual query scope and page size but adds no new syntax or format detail, so the baseline applies.
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?
States a specific verb and resource ('Find manga series on Mangainfo') plus the key capability: lookup by any title in English, romaji, Japanese or another name. This implicitly separates it from get_series, which the sibling list suggests is a slug-based lookup, but no sibling is named outright.
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?
The description makes the use case inferable — search when you have a title rather than an identifier — but it never states when to prefer get_series or get_series_volumes over this tool, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the anime of a manga series ends in the manga: the chapters each TV season or film adapts, the chapter and Japanese volume to read on from, and the English edition of that volume with its date. Only ranges an editor checked. Takes a slug such as "oshi-no-ko" or a title.
| Name | Required | Description | Default |
|---|---|---|---|
| series | Yes | The slug from a Mangainfo address (mangainfo.com/series/oshi-no-ko is oshi-no-ko) or a title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's job is to add data-quality context. It does: 'Only ranges an editor checked' warns the agent that coverage may be partial, and it enumerates exactly what fields come back, which matters with no output schema.
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?
Front-loaded with the payoff (where the anime ends) followed by the field list and the input hint; every clause earns its place. The trailing 'Takes a slug such as...' slightly duplicates the schema, costing a point.
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?
With no output schema, the description carries the return-value burden and does so fully — season/film chapter ranges, continuation chapter and volume, and the English edition with date. It also flags the editor-verified coverage caveat, leaving nothing material unspecified.
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% and the schema already explains the slug-or-title distinction. The description merely restates the slug example ('oshi-no-ko'), adding no new semantics, so the baseline 3 applies.
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?
States a specific resource and the exact payload: chapters each TV season or film adapts, the chapter and Japanese volume to read on from, and the English edition with date. This is far more specific than any sibling (search_series, get_series_volumes, get_series); an agent cannot confuse this with a generic series lookup.
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?
Clear context for invocation — you supply a series slug or title and get anime-to-manga mapping — plus a concrete input example ('oshi-no-ko'). It stops short of naming when to prefer a sibling like get_series_volumes instead, so no exclusions are given.
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.
get_new_licensesget_releasesget_reportget_seriesget_series_volumeslookup_isbnsearch_serieswhere_anime_endsFree anime, manga & webtoon directory: search 57k titles, recommendations, airing, where to stream.
Anime watch order, no guesswork. Watch orders, filler guides, title search, airing this week.
Comic book database — search comics, creators, characters, and manage your collection.
Access and interact with anime and manga data seamlessly. Retrieve detailed information about your…
Add one secure layer between your agents and this server.
