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 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 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 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?

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 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?

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, 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.