JMComic AI

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

No annotations are provided, so the description carries the full burden. It discloses the auth requirement, the duplicate-favorite behavior (returns error and does not change state), and the meaning of the returned message field. This goes well beyond a minimal mutation description.

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 well structured with a short action statement followed by compact Parameters and Returns sections. Every sentence adds meaningful information, and the key duplicate behavior is noted early.

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 favorite-add tool, the description covers the auth prerequisite, side effects, parameter normalization, and the full return contract. There are no critical operational gaps given the tool's simplicity.

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?

The input schema only gives album_id as a string, so the description adds essential semantics: it accepts an album ID, a JM prefix, or an album link, and normalizes to a pure numeric string. This is exactly the enrichment an agent needs to invoke the tool correctly.

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 uses a specific verb and resource: add an album to the current logged-in account's favorites. It clearly differentiates from sibling tools like delete_favorite_album and browse_favorite_albums.

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 states a clear prerequisite: a valid login session or Cookie is required. It does not explicitly name alternatives or say when not to use the tool, but the action is unambiguous and the sibling names make the distinction evident.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses the return shape, reports that invalid parameters may produce an error, and clearly states that detailed statistics (likes/views/author) are absent, which prevents false expectations. It does not mention auth or rate limits, but those are not critical for a read-only browse tool.

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 longer than average, but the length is justified: it documents four parameters entirely, explains the return contract, and gives three representative examples. The content is organized into clear sections and the most important behavioral limitation is front-loaded before the detailed parameter list.

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 browse/ranking tool with no schema-level parameter documentation and no annotations, this description is complete. It covers all valid parameter values, defaults, pagination page semantics, return fields, error behavior, and the key limitation with routing to the correct sibling tool. Nothing essential for calling it correctly is missing.

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?

The input schema provides no descriptions and no enums, and schema coverage is 0%, so the description must fully compensate. It does so by listing every accepted value for category, time_range, and order_by, plus defaults for all parameters, and by adding practical examples showing meaningful combinations.

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 a specific verb+resource combination ('浏览、过滤、排行本子') and explains that the tool combines category browsing with ranking. It also distinguishes itself from get_album_detail by noting that detailed statistics are intentionally not included, so an agent can tell which tool to use.

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 gives clear usage context through parameter combinations and examples, and explicitly routes to get_album_detail() when detailed statistics are needed. It does not explicitly contrast with search_album, but the browse/filter/rank framing makes the intended use clear enough.

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

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

With no annotations provided, the description carries the full burden. It explains authentication behavior (username only needed for HTML cookie-only clients; API clients always use current account), pagination, and error conditions for invalid parameters. This goes well beyond the name and schema, though it stops short of describing rate limits or maximum page size.

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 opens with a clear one-sentence summary, then uses labeled sections for parameters and return fields. Every line carries necessary information with no filler or repetition.

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?

Given the 4 optional parameters and output schema, the description fully covers invocation requirements, auth nuances, and return shape. It includes error cases for invalid inputs enough for reliable use.

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 0%, so the description must compensate, and it does. Every parameter is documented with meaning and default: folder_id with the special '0' meaning all favorites, page starting at 1, order_by valid values, and username conditional behavior. This is richer than the bare input schema.

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 verb and resource: paginated browsing of a logged-in account's favorites, returning lightweight album summaries. This clearly distinguishes it from siblings like browse_albums or add_favorite_album by narrowing scope to favorites only.

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 gives clear context: it is for browsing the logged-in account's favoriteshare, and it explains the conditional username requirement for HTML cookie-only clients. It does not explicitly mention alternatives or when to use browse_albums instead, but the purpose is unambiguous.

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

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

With no annotations, the description carries the burden well: cooperative cancellation, idempotent re-cancel, in-flight HTTP requests finish first, files are NOT deleted, and the final result preserves completed items plus unfinished_ids. This is far richer than a bare 'cancel' and discloses side effects and lifecycle behavior clearly.

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 action and scope, then lifecycle and side-effect details. Sentences each carry distinct information (idempotency, polling requirement, file retention, resume path) with little redundancy.

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?

An output schema exists so return payloads needn't be spelled out, yet the description usefully characterizes the terminal result (completed items + unfinished_ids). Combined with lifecycle and idempotency notes, an agent has enough to invoke and follow through correctly.

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 0% and the single task_id parameter is undocumented in both schema and description. The description implies the task lives in a shared task directory but never states the expected id format or source, so it only partially compensates for the coverage gap.

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 (cancel) plus resource (background download task in a shared task directory) and immediately distinguishes the operation as cooperative. An agent can tell it apart from retry_download, start_download, and get_download_task without opening any schema.

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?

Explicitly notes that repeated cancellation is safe (idempotency guidance) and points to retry_download for resuming unfinished items, plus tells the agent to keep polling to terminal state. It lacks an explicit 'when not to use' clause, but the usage context is clear.

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

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

Since no annotations are supplied, this description carries the full load. It discloses the necessary prerequisite (valid login session or Cookie) and the no-op error when the album is not in favorites, which goes beyond the obvious 'delete' implication. It also summarizes the return structure, though it doesn't mention potential side effects or limits.

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 compact: two primary sentences plus clean parameter and return sections. No word is wasted, and the purpose and prerequisites are front-loaded, making it easy for an agent to parse quickly.

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 tool with an existing output schema, this description covers the key requirements: authentication, the edge-case failure, parameter semantics, and return fields. There is no meaningful missing information that would prevent correct invocation.

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?

The schema only declares 'album_id' as a string with no description, while the description explicitly says it supports a pure album ID, a JM prefix, or an album link. This meaningfully extends the schema and is essential for an agent to format the parameter correctly.

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 explicitly states the action: cancel the current account's favorite of an album, which clearly identifies the tool's purpose and distinguishes it from the sibling add_favorite_album. It also adds specific context about required authentication and the non-mutating failure case when the album is not already in favorites.

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 doesn't explicit name alternatives or state when-to-use versus add_favorite_album or browse_favorite_albums. It provides useful context such as requiring a valid login session/Cookie and the error behavior, but usage is mainly inferred from the tool name and the singular action.

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

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

With no annotations provided, the description carries the full burden and does it well: it discloses blocking semantics ('会等待下载完成后返回'), real-time progress through logs and MCP Context, cache-hit behavior in image_paths, a per-call log_path, task_id, and an error field on failure. This gives an agent a concrete execution model for a long-running, side-effecting operation.

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?

Well-structured and front-loaded: a one-line summary, then behavior, then parameters, then return fields. The nine-field return listing is lengthy, but it is the only return documentation available since the output schema is not shown in the definition, so every sentence earns its place.

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 single-required-param download tool with no annotations, coverage is strong: purpose, blocking behavior, parameter format, progress reporting, return structure, and failure reporting are all documented. The notable gaps are lack of prerequisites (login is a sibling tool) and lack of explicit routing against download_photo/download_cover, which would make it fully 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 0% and the schema only names album_id as a string, so the description must compensate. It adds an example format ('123456') for album_id and, crucially, documents the ctx parameter as auto-injected by FastMCP — preventing the agent from attempting to pass a parameter that is not part of the input schema.

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 — '在后台下载整个本子' (download the entire album) — which an agent can immediately distinguish from the download_photo and download_cover siblings. The '在后台' (in background) phrasing is mildly confusing because the very next sentence declares it a blocking operation, which prevents 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 '整个本子' (entire album) implicitly tells an agent this is the tool for full albums rather than single photos (download_photo) or covers (download_cover), but no explicit when-to-use/when-not-to-use guidance is given and no alternative tool is named. Prerequisites such as authentication are not mentioned, even though a login sibling exists.

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

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

With no annotations, the description carries the full burden and delivers: it discloses failure semantics (partial on some failures, failed on all), the id vs actual_id distinction, cooperative cancellation on caller disconnect, and live progress notification via injected MCP Context. This is far beyond what the schema provides.

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 core purpose is front-loaded in the first sentence and no sentence is filler, but the body is dense with stacked parentheticals, making it longer than strictly necessary for scanning.

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?

An output schema exists, so return values need not be explained, yet the description usefully clarifies the partial/failed status semantics and the item id mapping. Coverage is broad (concurrency, failure modes, cancellation, alternatives) with only minor gaps such as permissions/auth context.

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 0%, so the description must compensate. It explains the non-obvious concurrency params well (album_workers default 3 and album-only; photo/image_workers and their inherited defaults), and gestures at kind (album/photo) and export_formats (zip/pdf/long_img). ids is left implicit, so it is strong but not complete.

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 ('有界批量下载并等待整批结果') plus the supported kinds (album/photo) and export formats, making it clearly distinguishable from the single-item siblings download_album/download_photo and the async start_download.

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?

Explicitly names the alternative and the selecting condition: '适合短批次；需要提前拿到 task_id、轮询及主动取消时使用 start_download.' This tells the agent both when to use this tool and when to route elsewhere.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states that the file is saved to a 'covers' subdirectory by default, that an alternate output directory can be supplied, and that the return value is a success message with the saved path. It omits details like overwrite behavior or directory creation, but the main side effects are disclosed.

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 compact, front-loaded with the core purpose, and then organized into clear sections for parameters and return value. Every sentence contributes necessary information, and there is no unnecessary repetition of schema fields.

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 two-parameter download tool, the description covers the action, default directory, optional override, and return message, and an output schema exists. It is not fully complete because it lacks guidance on error scenarios, overwrite behavior, or how this tool relates to sibling downloading tools, but it is sufficiently complete for basic selection and invocation.

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 0%, so the description must fully explain parameters. It does: album_id is defined as the album ID with an example, and output_dir is defined as an optional output directory with the default behavior explicitly stated. This adds meaning well beyond the bare schema property names.

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 verb and resource: '下载特定本子的封面图片' (download the cover image of a specific album). This is clear and distinct from the main resource, but it does not explicitly differentiate itself from download_album or download_photo, whose scope could overlap with downloading cover images.

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 intended use is implied by the purpose statement: use this tool when you need an album's cover image. However, the description gives no explicit guidance about when to prefer this over sibling tools like download_album or download_photo, nor does it mention any exclusions or alternatives.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It does this well by revealing caching behavior ('命中缓存'), local filesystem writes (download_path, image_paths), per-call logs (log_path), task_id, and error reporting. It does not mention authentication or cleanup of downloaded files, but the disclosed behavior is substantial.

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 purpose statement is front-loaded and the parameter/return sections are clearly separated. The return dictionary is somewhat verbose, but each field adds operational context (paths, task IDs, logs, durations), so the length is justified rather than bloated.

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?

Given the tool's simplicity (one required parameter) and the detailed return contract, the description is largely complete. The main gaps are the absence of explicit usage boundaries against sibling download tools and lack of authentication/storage side-effect notes, but the extensive output semantics and parameter explanation make this more than minimally viable.

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?

The schema provides only the parameter name photo_id with no description, so schema coverage is 0%. The tool description fully compensates by explicitly defining photo_id as the chapter ID and providing a concrete example ('123456'). This gives an agent everything needed to understand the sole parameter.

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 concrete action and resource: '下载本子中的特定章节' (download a specific chapter of a book). This is more specific than a mere restatement of the tool name and is distinguishable by chapter-level scope from siblings like download_album and download_cover. However, the parameter name photo_id conflicts slightly with the 'chapter ID' concept, creating minor ambiguity.

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 intended use is implied: use this when downloading a specific chapter rather than a full album or cover. But the description does not explicitly state when to prefer this tool over download_album or download_cover, nor does it mention prerequisites such as login or whether the chapter must belong to a downloaded album.

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

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

With no annotations, the description must carry behavioral disclosure; it usefully explains pagination, recursive replies, spoiler flags, and null behavior for total/page_count. However, it does not state authentication needs, read-only guarantees, or error behavior for invalid album_id/page.

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 opening sentence is front-loaded and the parameter/return sections are clearly structured and reasonably compact. A minor deduction: the detailed return field list overlaps with the available output schema, adding length beyond the strict minimum.

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 low-complexity, two-parameter read tool, the description covers purpose, parameter semantics, and return semantics including nullability. It lacks usage-routing context relative to sibling tools, which is the main completeness gap.

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 0%, and the description fully compensates by explaining album_id's identity with an example and page's 1-based, defaulted value. This adds meaning the input schema alone cannot provide.

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 clear action ('获取本子的一页评论') with the album/comments resource and scope, and adds distinctive features of recursive replies and spoiler flags. It does not explicitly contrast with the sibling get_forum_comments, so it falls just short of full differentiation.

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?

There is no guidance on when to choose this tool over alternatives such as get_forum_comments or when paginated access is needed. The description implies the use case through its name and wording, but does not state exclusions or alternatives.

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

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

There are no annotations, so the description must convey behavior. It discloses the return structure (a dictionary with specific fields), which is useful, and the read-only nature is implied by 'get'. However, it does not mention authentication requirements, possible errors, or any side effects beyond fetching data.

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 compact and front-loaded with the core purpose, followed by a clear parameter explanation and a return-field list. Every part adds value, though the return list is somewhat redundant given that an output schema exists.

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 getter, the description covers the essential input and output. However, it does not explain how to obtain an album_id, whether a login session is required, or what happens on failure. The presence of a login sibling suggests auth context may matter, and that is not addressed.

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?

The input schema provides no parameter description (0% coverage), so the description compensates well by explaining album_id as '本子 ID' and giving a concrete example. For a single-string parameter, this is sufficient and removes ambiguity.

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 clearly states the tool retrieves detailed information for a specific album, with a concrete verb and resource. It is distinguishable from sibling tools like browse_albums and search_album, though it does not explicitly name those alternatives.

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 implies the tool is for fetching details about one album once an album_id is known, but it provides no explicit guidance about when to prefer this over search_album, browse_albums, or get_album_comments. No exclusions or alternative routing are mentioned.

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

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

With no annotations, the description carries the whole burden and does so well: it defines the in-progress vs terminal status sets, explains that items.success means the whole item finished, clarifies that completed_images includes cache hits and is not a network-transfer count, and notes the manifest is only final after the batch收尾. It does not cover error behaviour for unknown/expired task_ids, which keeps it from 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?

Front-loaded purpose sentence followed by compact, high-density notes on status sets and counter semantics; no filler. The enumerated status lists are slightly compressed and harder to scan than prose or a table would be, but 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?

An output schema exists, so return-field documentation is not required, and the description still adds the semantic layer (status lifecycle, meaning of success/unfinished_ids, what the manifest is). The only real gap is that an agent is never told how to obtain a task_id or that terminal status means further polling is pointless.

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?

The single required parameter task_id has 0% schema description coverage, and the description never explains it — not where the ID comes from (e.g. download_batch/start_download) nor whether it survives restarts, even though cross-restart reports are mentioned. The description's rich content is entirely about return semantics, so it fails to compensate for the coverage gap on the one input it takes.

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 — querying background download status, processed-image count, and the order-preserving manifest, plus reading the cross-restart task report. It is clearly distinguishable from siblings like cancel_download, retry_download and download_batch.

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 context is clear (poll progress / inspect a finished or interrupted batch) and it explicitly routes the agent onward: unfinished_ids can be fed to retry_download. It never states when NOT to use it or that polling is the intended pattern, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the behavioral burden. It explains authentication-dependent behavior, the return structure, empty-list behavior, and the special folder_id="0" caveat for querying all favorites. It does not cover error or unauthorized-access behavior, but for a simple read-only getter this is a minor omission.

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 purpose and then organized into labeled 参数 and 返回 sections. Every sentence adds useful operational detail, with no filler or repeated schema information.

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 single-optional-parameter getter with an output schema, the description covers auth context, parameter semantics, return shape, empty-state behavior, and an edge case. An agent has enough information to invoke the tool correctly and interpret the result.

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 0%, but the description fully documents the only parameter, username, including when to provide it, when to omit it, and how HTML vs API clients treat it. It also explains the special folder_id="0" semantics that are not visible in the input schema.

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 first line states a specific verb and resource: retrieving the logged-in account's favorite folders. This clearly distinguishes it from sibling album tools like browse_favorite_albums and add_favorite_album even without naming them. The follow-up notes about username and returned fields reinforce the scope.

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 gives concrete usage context: HTML clients with only a cookie must supply username, callers who logged in via login may omit it, and API clients should omit it and always query the current account. It does not explicitly name alternatives or say when not to use the tool, but the invocation conditions are clear.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses pagination semantics, the returned dictionary fields, and a behavioral nuance: HTML clients receive null for total and page_count. This is useful context beyond a simple read-only statement, though it does not discuss auth or rate limits.

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 compact and well-structured with '参数' and '返回' sections. Every sentence adds information: what the tool does, what the parameter means, and what the return shape is. There is no filler or redundancy.

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 low-complexity tool with one optional parameter and an output schema, the description covers the essential invocation details: pagination, return structure, and client-specific null behavior. It does not provide routing context or mention authentication prerequisites, but those are secondary for this simple read operation.

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 0%, so the description must compensate. It does: the '参数' section defines page as a comment page number starting from 1 with a default value of 1, which goes beyond the schema's type/default. The single parameter is fully described, but no examples or edge cases are given.

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 clearly states the action ('获取全站最新发布的一页评论') with a specific resource and scope: site-wide latest comments. It also lists the main payload contents (parent album, recursive replies, spoiler flags). It does not explicitly name or contrast with the sibling get_album_comments, though '全站' implies a site-wide scope rather than an album-scoped one.

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?

No guidance is given on when to use this tool versus alternatives. A sibling tool get_album_comments exists, but the description does not mention it or provide any selection criteria. The agent must infer that this tool is for site-wide comments and the sibling is for album-specific comments.

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

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

With no annotations provided, the description carries the burden of disclosing side effects. It transparently states that a session cookie is saved for future requests. It does not discuss credential handling or possible failure modes, but the core side effect is disclosed.

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 short, direct, and well-structured with clear sections for purpose, side effect, parameters, and return value. Every sentence adds useful information without unnecessary elaboration.

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 login tool, the description covers the purpose, the session-cookie side effect, the parameters, and the expected return message. It is complete enough for an agent to understand when and how to invoke the tool successfully.

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?

The schema provides only bare parameter names with no descriptions, and the description merely restates them as '用户名' and '密码' without adding any constraints, formats, or behavioral details. Since schema coverage is effectively zero, the description needed to compensate and did not.

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 clearly states the verb 'login' and the resource 'JMComic account', and explains the purpose of accessing additional features. It is distinct from the sibling tools, which are all album/comment/option operations, leaving no ambiguity about what this tool does.

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 when to use the tool: to access more features like favorites and premium content. It also notes that the session cookie is automatically saved for future requests, implying login should occur before other authenticated operations. It does not explicitly mention alternatives, but no sibling tool performs authentication.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that no metadata or images are requested by default, that init plugins still run per their own behavior, that include_details=True performs network reads with per-item failure isolation, that no size/time estimation is done, and that a missing img2pdf yields an actionable error without auto-install. Remaining gaps (auth needs, rate limits, write/side-effect profile) keep it from 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?

Front-loads the core purpose in the first line, then groups parameter behavior and edge-case disclosures. The description is long and clause-dense, but for a 7-parameter tool with zero schema coverage and no annotations, nearly every sentence carries useful information.

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?

Given an output schema exists, return values needn't be explained, and the description instead covers behavior, parameter meaning, concurrency defaults, and error handling for a fairly complex tool. It is nearly complete; the main omission is any explicit positioning against the actual download siblings it previews for.

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 0%, so the description must compensate, and it largely does: it explains kind (album/photo), export_formats (zip/pdf/long_img), album_workers (albums only, default 3), photo_workers/image_workers (batch chapter/image caps inheriting download.threading defaults), and include_details semantics. Only the required 'ids' parameter's concrete format/kind coupling is left implicit, but it is covered by the ID-normalization clause.

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 + resource in '下载前预览' and enumerates exactly what it does (normalize/dedupe IDs, resolve output root, set global concurrency caps) and what it does NOT do ('不下载图片'). This clearly separates it from sibling download/start tools like download_batch, download_album, and start_download.

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 'before download' framing implies when to use it, and include_details=True is positioned as the path for selecting a subset of chapters. However, it never explicitly names an alternative tool or states when NOT to call this versus download_batch/start_download, so the guidance remains implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that original files may be deleted via delete_original_file, explains the processing outputs, and describes the return status and paths. It does not mention overwrite behavior or default deletion, but it is substantially transparent for a processing tool.

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 well-structured with clear sections, front-loads the purpose, and gives parameter details in an easy-to-scan format. The return section is somewhat redundant given the output schema exists, but it is concise and informative without excessive verbosity.

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?

Given the tool's moderate complexity, the description covers all parameters, allowed values, output format examples, and return fields. It lacks explicit usage boundaries and default deletion behavior, but with an output schema available and detailed parameter semantics, it is largely complete for correct invocation.

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 0%, so the description must fully compensate. It provides meaning for every parameter: album_id is defined, process_type has explicit allowed values, and params is detailed with a concrete dir_rule example and the delete_original_file boolean semantics. This far exceeds what the bare schema provides.

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 action: post-processing already downloaded albums into Zip, PDF, or long images. This clearly distinguishes it from download-related siblings like download_album and download_photo, and the output formats make the tool's purpose concrete.

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 '已下载的本子' implies the tool should be used after an album has been downloaded, but there is no explicit guidance on when not to use it or which sibling tool to choose instead. Usage context 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.

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

With no annotations, the description carries the full disclosure burden, and it does well: it states that the original download kind, concurrency, export format, report, and task ID are preserved, that current config/account are used, that images come from upstream cache, that completed items are not re-downloaded, and exactly which conditions yield an error. It omits permission/auth requirements and whether the call is side-effecting on the original task, which keeps it below 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?

The description is three tight lines that lead with the action and then add semantics and error conditions; every sentence carries information. The only inefficiency is that the cache/config details could be compressed.

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?

Because an output schema exists, return values needn't be explained, and the description covers the mutation's effects, state preconditions, and failure modes well. The main gap is that it doesn't say what to do next when the error is returned, for example which tool to call or how to inspect task state.

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?

There is a single parameter, task_id, and the schema provides no description at all (0% coverage). The description implies a key semantic constraint — the ID must refer to a terminal (non-running) task with unfinished items — which is genuinely useful, but it doesn't spell out what task_id is or where to get it, for example from get_download_task.

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 verb+resource: create a new background task for the unfinished items of a terminal task, preserving the original report and task ID. This implicitly distinguishes it from start_download/download_batch by scoping it to an already-terminal task, but it never names those siblings 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?

It clearly describes the precondition (the original task must be terminal) and two negative cases that produce an error: no unfinished items, or the task still running. It gives clear context for when to call it, though it doesn't explicitly route the agent to an alternative tool for those error cases.

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

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

The description discloses that the tool returns a dictionary with albums, total_count, and an optional error field when order_by or time_range are invalid. However, it does not mention whether the operation is read-only or highlight any side effects, though the search nature implies read-only behavior.

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 well-organized with a brief intro followed by a bulleted parameter list, making it easy to parse. While it is slightly verbose in repeating default values and explanations, it remains focused and avoids unnecessary fluff.

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?

The return structure is described at a high level (albums, total_count, error) and the error condition is specified. Although the detailed shape of each album item is not included, that information is likely provided by related tools (e.g., browse_albums or get_album_detail), so the description is sufficiently complete for the tool's scope.

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?

Every parameter is explained with specific meaning and allowed values. For example, keyword is described as supporting album ID, title, author, and tags, and order_by and time_range each have explicit value lists with Chinese descriptions. This adds substantial semantic detail beyond the bare schema types and defaults.

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 clearly states the tool's purpose: '搜索本子' (search albums), and it explicitly mentions supporting advanced filter options. The verb 'search' distinguishes it from sibling tools like browse_albums or get_album_detail, making the action and resource unambiguous.

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 does not explicitly state when to use this tool versus the sibling tools, such as browse_albums or get_album_detail. No conditions or alternative scenarios are mentioned, leaving the agent to infer usage context from the parameter list alone.

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

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

With no annotations at all, the description carries the full burden and discloses substantial operational behavior: the task is stateful and owned by the current server (shutdown interrupts it), reports survive restarts, thread pools are shared across the whole batch, a service supports at most four batches, no config is mutated, and there is no hidden truncation. It also explains the id vs actual_id distinction and dedup ordering — exactly the kind of context annotations would otherwise need to supply.

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 most important facts — what starts, what is returned, and the follow-up tools — are front-loaded into the first and last sentences, and the middle sentences are information-dense rather than padded. It is somewhat run-on and one clause ('不同时向用户说明两者') is ambiguous, so it is not maximally crisp.

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?

An output schema exists, so return values need not be fully described, and the description still names the key return fields plus lifecycle and concurrency constraints. It is complete enough to invoke correctly, though failure behavior and the precise shape of the returned batch record are left implicit.

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 0%, so the description must compensate, and it largely does: it defines kind=album/photo, explains that ids accepts IDs or links deduped by first occurrence, describes each of album_workers/photo_workers/image_workers (including that the latter two default to download.threading.* config and are scoped differently), and enumerates export_formats values (zip/pdf/long_img). The ids description is entangled with the dedup sentence and does not state accepted formats, preventing 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 a specific verb and resource ('立即启动后台批量下载') and states the return values (task_id, log_path, report_path), so the agent knows exactly what the tool produces. It names follow-up tools (get_download_task, cancel_download) and clarifies post_process is unnecessary, but it never distinguishes start_download from close siblings like download_batch, download_album, or plan_download.

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?

It gives clear lifecycle guidance (query with get_download_task, cancel with cancel_download) and notes export_formats removes the need for post_process, which is genuinely useful routing. However, with siblings such as download_batch, download_album, download_photo, plan_download, and retry_download present, it offers no criteria for choosing this tool over them — usage is only implied by 'batch download'.

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

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

With no annotations, the description carries the burden and does meaningful work: it discloses merge semantics, file persistence, limited validation, and the success/error return shape. It does not detail backup behavior or consequences of a bad update beyond the warning, but 'only performs limited validation' plus the recommendation to consult schema/reference covers the main risk.

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 purpose, then gives the critical warning, parameter explanation, return behavior, and a compact example. Every section earns its place and no sentence is filler.

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 an open-ended nested config object with no annotation support, the description supplies enough to invoke it and routes the agent to the authoritative syntax resources. It also covers return shape even though an output schema exists. Full JmOption syntax is intentionally not embedded here, but the description compensates with references and an example.

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?

The input schema is minimal (open object with additionalProperties true and 0% coverage), so the description must compensate. It does so by defining option_updates as a merge dictionary, naming supported nested areas (client, download, dir_rule), and providing a concrete example. It does not enumerate the full option grammar, but explicitly delegates that to jmcomic://option/schema and /reference.

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 first sentence states a concrete action ('更新 JMComic 配置') with a clear resource and persistent effect ('保存到文件'). It is distinct from all sibling tools, which concern login, downloads, album browsing, and post-processing; this is unambiguously the config-update tool.

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 gives clear context: it is for merging JmOption updates into the saved config and emphasizes reading the option schema/reference before calling because validation is limited. It does not explicitly name alternatives or say 'do not use for X', but among the sibling list there is no close alternative and the intended when is clear.

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