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

Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar for the description is lower. The description adds genuine behavioral context beyond annotations: the tool performs validation (it can reject malformed input) and makes no network request, implying no rate-limit, auth, or latency concerns. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single 21-word sentence that front-loads the action and resource, enumerates the input condition types, and closes with the key no-network constraint. Every phrase carries information and there is zero 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?

The output schema covers the return shape, the 100% schema coverage documents all five optional parameters, and the four annotations establish the safety profile. The description adds the validation behavior and offline nature, leaving only minor gaps such as explicit failure semantics and the unstated-but-implied intent that the generated query feeds a subsequent search call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter already documented (e.g., 'Up to 10 tags that results must exclude', 'Up to 10 tags combined as an OR condition'), so the baseline is 3. The description groups the parameters into condition categories (include, exclude, OR, exact-tag, title), which frames their roles holistically, but it adds no detail beyond what the schema already 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 verb ('build and validate') against a specific resource ('native search syntax'), and enumerates the exact condition types it composes: include, exclude, OR, exact-tag, and title. The clause 'without making a network request' sharply distinguishes this offline query builder from the 28 sibling search and query tools, so an agent can tell it apart without inspecting schemas.

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 'without making a network request' clause implies an offline, preparation-oriented use case — constructing and pre-validating a query before a search is executed. However, the description never explicitly names an alternative, states when-not-to-use it, or tells the agent to pass the result into a sibling like eh_search_galleries, leaving the routing to inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying exactly which access-related states are diagnosed (reachability, auth state, Cloudflare challenge), going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action ('Diagnose') and then lists the three diagnostic domains. Every word contributes to understanding the tool's purpose, 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?

For a simple, optional-parameter, read-only diagnostic tool with rich annotations, the description is nearly complete. The only notable gap is that it does not describe the return format or result structure, but the tool's purpose and safety profile are clear enough for an agent to select and invoke it 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 description coverage is 100%: the 'site' parameter is fully documented with an enum and a clear description. The tool description itself adds no additional parameter meaning, which matches the baseline for a fully covered simple schema. Minor note: the schema's mention of 'URL override' does not correspond to any visible URL 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 immediately identifies the tool as a diagnostic action ('Diagnose') with a specific resource scope: reachability, authentication state, and Cloudflare challenge state for E-Hentai or ExHentai. This clearly distinguishes it from the sibling gallery/favorite/search tools, which are all data-retrieval or management operations.

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 diagnosing access issues but provides no explicit guidance on when to choose it over sibling tools or when not to use it. There is no mention of alternative tools or conditions that would make another tool more appropriate.

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?

Annotations already establish this as safe, read-only, idempotent, and non-destructive. The description adds useful behavioral detail by specifying exactly which attributes are compared, including namespaced tag additions/removals, without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no filler. The core verb and resource appear first, followed by the comparison dimensions, and every word contributes meaning.

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 tool is a read-only comparison with an output schema, fully documented parameters, and annotations covering safety and idempotency. The description plus structured metadata gives an agent everything needed to call it 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 description coverage is 100%, with before/after and site all documented in the schema. The description adds no parameter-level detail, so the baseline of 3 is appropriate; it neither helps nor hurts beyond the 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 uses a specific verb ('Compare'), a clear resource ('two gallery versions'), and enumerates the exact dimensions compared (title, posted time, page count, file size, tag changes), making the tool's purpose unmistakable and distinct from sibling tools like eh_find_latest_gallery_version or eh_get_gallery_chain.

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 what the tool does but gives no guidance on when to choose it over alternatives such as eh_get_gallery_chain or eh_find_latest_gallery_version. There are no explicit use cases, exclusions, or context for selecting this tool.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond that by listing the error conditions: invalid references, deleted galleries, authentication failures, challenge pages, and upstream errors are returned as tool errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler. The core action is front-loaded, the sibling alternative is stated immediately after, and the error contract is a single compact sentence. 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?

With an output schema present, the return value does not need explanation. The description covers scope, the alternative tool, and failure behavior, which is complete for a read-only resolution tool with well-annotated safety hints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters and their relationships (gallery vs galleryUrl, site override behavior). The description does not add meaningful parameter-level detail beyond saying 'one gallery,' which is sufficient given the schema's completeness. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: resolve one gallery's official and detail-page version chain and return the latest semantic version. It also names the sibling tool 'eh_get_gallery_chain' as the one for the complete chain, clearly differentiating this tool's 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?

It explicitly tells the agent when to use a sibling instead: 'Use eh_get_gallery_chain when the complete ordered chain is needed.' This directly establishes the use condition and the alternative, which is exactly what an agent needs to choose correctly.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds genuine behavioral value on top by disclosing the fallback chain (title → artist tag → uploader) and the exact-quoted search strategy, which shapes how results degrade and what an agent can expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the core purpose and then packs the full strategy and fallback chain into a compact clause sequence. Every element earns its place with zero 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?

With a rich output schema, fully described parameters, and safety annotations, the description covers the essential behavioral nuance. The only minor gap is the terminal fallback case: what happens if no title, no artist tag, and no uploader remain is unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents site, gallery (gid/token), and galleryUrl, including the mutual-exclusivity constraint. The description's strategy narrative is behavioral rather than parameter-specific, so it adds no additional meaning beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Find galleries') plus the defining strategy ('EhViewer's strategy: extract a structural title and run an exact quoted search'). This clearly differentiates it from sibling search tools: it finds similar galleries by metadata rather than exact hash or file matches like eh_search_by_hash or eh_search_by_file.

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's strategy explanation makes the usage context clear: use this when you have a gallery and want similar results based on title, artist tag, or uploader. However, it never explicitly names alternatives or states when not to use it (e.g., for exact duplicates), leaving some routing to inference despite a large sibling family.

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?

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), the description reveals meaningful behavioral traits: serial enumeration, complete/ordered output, and no image downloads. These traits help an agent set expectations about performance and side effects. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the core behavior and constraints with no filler. Every phrase contributes: 'serially', 'every gallery preview page', 'complete, ordered image-page list', and 'without downloading images'.

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 rich output schema and annotations, the description adds the essential behavioral context an agent needs to select and invoke the tool correctly. It clearly states what the tool does, how it behaves, and what it avoids, leaving parameter details to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about parameters like site, gallery, maxImages, or galleryUrl; it relies entirely on the schema for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('enumerate'), resource ('every gallery preview page'), and result ('complete, ordered image-page list'), plus a scope constraint ('without downloading images'). It does not explicitly differentiate this from the sibling eh_get_gallery_pages, though the 'every' phrasing implies broader coverage.

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 conveys a clear usage context: use this when you need a complete, ordered enumeration of gallery image pages without downloading the images themselves. However, it does not explicitly name alternatives or state when not to use it, so it falls short of explicit routing 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value by explicitly noting that no purchase or archive-key consumption occurs, and by indicating the operation reflects the authenticated user's balance. This goes beyond a generic read-only declaration, though it omits details like error or rate-limit 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 entire description is one tight sentence that front-loads the key behavior and result contents, followed by an explicit non-side-effect guarantee. There is no filler or repetition of schema details.

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?

Combined with a rich input schema, an output schema, and annotations indicating safe read-only behavior, the description fully covers what the tool does and its side-effect profile. Nothing critical needed for an agent to select and invoke the tool 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?

Schema description coverage is 100%, so the input schema fully documents the site, gallery object, and galleryUrl parameters. The description does not add additional parameter-level meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and names the exact resource ('authenticated archive page's balance, available resolutions, sizes, and costs'), while explicitly noting it does not purchase or return archive keys. This clearly distinguishes it from the many read-oriented sibling tools like eh_get_gallery_detail or eh_get_all_gallery_pages.

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 'without purchasing or returning archive keys' clearly frames this as a pre-purchase inspection tool for archive options. It does not explicitly name alternatives or state when not to use it, but the context is sufficiently clear for an agent to know when this tool is relevant.

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 annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the description's 'without modifying favorites' adds no new safety information. However, it does add behavioral context beyond the annotations by specifying that the result is scoped to the authenticated user, limited to ten categories, and includes counts/total/current selection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence front-loads the action, resource, and exact data delivered, with no filler or repetition. The phrase 'without modifying favorites' earns its place by reinforcing the read-only contract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a complete input schema, an output schema available, and annotations covering safety, the description adds exactly the missing context: the user-scoped ten-category summary and current-selection behavior. Nothing essential is missing for an agent to invoke this tool 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 description coverage is 100%, and the one parameter (site) has a clear enum, default, and description. The tool description does not restate parameter behavior, which is acceptable because the schema already carries the full semantic burden. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and names both the resource ('favorite categories') and the exact returned data ('names, counts, total, current selection'), making the tool's purpose unambiguous. It also explicitly distinguishes this from mutation by adding 'without modifying 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 makes the read-only use case clear—retrieve the authenticated user's favorite-category summary—but it does not mention when to prefer this tool over siblings like eh_get_favorite_detail or eh_search_favorites, nor any exclusion criteria. Usage context is implied by the resource name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by noting the result is 'authenticated' (user-specific state) and explicitly lists the data returned, going slightly beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that communicates the action, scope, and key output fields without wasted words. It is concise and easily scannable.

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 rich input schema, output schema, and safety annotations, the description sufficiently covers what the tool does. The only minor gap is that 'authenticated' hints at auth requirements without stating whether authentication is mandatory or how missing auth is handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with detailed parameter descriptions for site, gallery, and galleryUrl, including mutual exclusivity. The tool description does not add parameter-level meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and names the exact resource: one gallery's authenticated favorite state, category, note, and favorite timestamp. It clearly distinguishes from siblings like eh_get_gallery_detail (metadata) and eh_search_favorites (search over favorites) by emphasizing 'one gallery' and 'favorite state'.

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 no guidance on when to use this tool versus alternatives such as eh_search_favorites or eh_get_favorite_categories. It states what it does but not the conditions that would make it the right choice.

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?

Annotations already mark the operation read-only, idempotent, and non-destructive; the description adds value by spelling out error semantics: deleted galleries, malformed URLs, authentication failures, challenge pages, and upstream request errors are surfaced as tool errors rather than empty chains. It also discloses ordering and deduplication behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences: the first states what the tool does, and the second covers the input constraint and failure behavior. There is no filler, no repetition of annotation content, and every clause 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?

Given that an output schema exists and annotations already cover read-only, open-world, and idempotent behavior, the description is sufficient for correct invocation: it identifies inputs, the one-of constraint, the combination logic, and the error contract. It does not need to describe return values because the output schema handles that.

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 already documents all three parameters with 100% coverage, including the mutual-exclusion constraint and site override behavior, so the baseline is 3. The description's 'exactly one gallery reference or full gallery URL' restates schema semantics but does not add new parameter-level detail beyond what the 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?

States a specific action ('Combine...') and a concrete result ('ordered, deduplicated gallery version list'). It also names two distinct data sources, which sets it apart from sibling lookup tools like eh_get_gallery_metadata or eh_find_latest_gallery_version, even without naming them.

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 retrieving a full ordered version chain rather than a single version or a comparison, but it never explicitly says 'use this when...' or names alternatives like eh_find_latest_gallery_version or eh_compare_gallery_versions. 'Provide exactly one gallery reference or full gallery URL' is an input constraint, not when-to-use guidance, so the agent must infer applicability from the phrase 'gallery version list.'

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?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds genuinely useful context beyond those cues by warning that comments are untrusted plain text and disclosing that scores, vote summaries, and possibly below-threshold comments are included. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence front-loads the core action and resource, then packs the important caveats (untrusted text, scores/vote summaries, hidden threshold) with no wasted words. Every clause adds relevant 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?

With a full output schema and 100% parameter coverage, the description only needs to convey purpose, data trust, and the optional hidden-comments behavior, which it does clearly. Nothing an agent needs to call this tool 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?

Schema description coverage is 100%, so the structured schema already fully documents site, gallery, galleryUrl, and includeHidden along with constraints and defaults. The description adds only slight reinforcement of the includeHidden option, which meets the baseline but does not substantially extend the 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 names a specific action ('Read') and a distinct resource ('uploader and user comments'), then adds what is included (scores, vote summaries) and a key option (below-threshold comments). This clearly separates it from sibling gallery metadata, search, and page-fetching tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's context explicit: it is the tool for reading gallery comments, and there is no comment-specific alternative among the siblings. It doesn't list exclusions, but none are essential given that the resource is unique; the optional hidden-comments behavior also signals when includeHidden should be used.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context by disclosing that the uploader-provided description is untrusted text and by specifying what data is included in the detail page, which helps the agent interpret results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy: the first sentence front-loads the tool's core function and deliverables, and the second sentence provides concise alternative routing. 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 tool with a rich output schema, nested parameters, and many siblings, the description is complete: it states what the tool returns, flags the untrusted text caveat, and names the relevant alternatives. It leaves nothing critical unexplained for an agent to invoke it 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 description coverage is 100%, so every parameter is already documented in the schema, including the site enum, gallery object with gid/token, and galleryUrl. The description does not need to add parameter-level meaning; the baseline of 3 applies because it adds no extra semantics beyond the 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 uses a specific verb ('Read') with a clear resource ('one gallery's detail page') and lists the actual content returned: structured fields, grouped tags with strength, rating statistics, parent/newer versions, and uploader description. It also names sibling tools that serve different purposes, making differentiation easy.

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 explicitly routes the agent to alternatives: eh_get_gallery_metadata for authoritative API metadata in batches, eh_get_gallery_comments for comments, and eh_get_torrents for torrent records and URLs. This gives clear when-to-use and when-not-to-use guidance beyond what the schema provides.

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?

readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false already establish that this is a safe read-only operation, so the description does not need to repeat that. It adds useful behavioral context by specifying the kind of authoritative data returned (namespaced tags, ratings, file size, torrent metadata, parent/current-version links) and the 1-25 batch limit without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earns its place: the first states the operation, scope, and content; the second routes to the preferred alternative. It is front-loaded and contains no 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 a batched metadata read with an output schema and thorough annotations, the description covers selection criteria, scope, and key content. The only missing details—site override behavior and exact response shape—are already covered by the input and output schemas. Agents have what they need to select and invoke the tool 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 description coverage is 100%, so the input schema already documents site, gid, token, and array constraints. The description adds no parameter-specific syntax or format guidance beyond 'gallery references,' which the schema already expresses. Baseline 3 is appropriate because the schema carries the semantic load.

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 'Get authoritative E-Hentai API metadata for 1-25 gallery references'—a specific verb, resource, and batch scope. It enumerates the metadata categories and explicitly contrasts itself with eh_get_gallery_detail, so an agent can distinguish it among the sibling tools.

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 final sentence is an explicit routing rule: 'Use this for structured metadata and version-chain inputs; use eh_get_gallery_detail for page-level fields, tag strength, or the uploader description.' This directly tells when to choose this tool over the closest alternative and names the alternative explicitly.

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?

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description's job is to add operational detail. It does this by disclosing that the server internally splits requests into official 25-item API batches and preserves input order, which impacts result mapping and rate expectations. It does not cover failure or partial-response behavior, but the annotation coverage reduces that burden.

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 two short sentences, each carrying a distinct fact: the batch capacity and the server-side batching/order behavior. It is front-loaded with the primary action and contains no filler or redundant schema duplication.

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 read-only batch metadata tool, the description sufficiently covers capacity, batching, and ordering; the output schema presumably documents the returned metadata. It remains slightly incomplete regarding explicit routing to the single-gallery sibling, but that is a minor gap given the tool name and sibling 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?

The input schema covers 100% of the parameters, including site, galleries, item requirements, maxItems, and input-order preservation. The description adds no new per-parameter meaning beyond repeating the count/order; the 25-item batching detail is operationally useful but not parameter semantics. Baseline 3 is appropriate because the schema already does the heavy lifting.

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 ('Get') and resource ('official metadata') with a clear scope ('up to 500 galleries'). The 'many'/'batch' phrasing and tool title distinguish it from the singular sibling eh_get_gallery_metadata, so an agent can identify the intended scope without opening the 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?

The description implies batch use through 'up to 500 galleries' and the batch name, and it notes batching behavior useful for understanding API execution. However, it does not explicitly say when to prefer this tool over eh_get_gallery_metadata for a single gallery or over eh_resolve_gallery_batch, so usage guidance is largely inferred from context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the output content and does not disclose external-site quirks, rate limits, or failure modes; however, it does not contradict the annotations.

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?

One sentence, front-loaded with the action and the key scope limit. There is no filler or redundant restating of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations cover the safety profile, so the description does not need to explain return values. The only notable gap is the lack of explicit sibling routing, but for a read-only single-page list operation with a fully documented schema, the definition is sufficiently 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?

The input schema documents 100% of parameters, including the gallery/galleryUrl mutual exclusivity, previewPage semantics, token pattern, and site enum. The description adds no parameter-level meaning beyond referring abstractly to 'one gallery preview page,' so the schema carries the burden.

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 ('List') and names the exact resource: image-page numbers, page tokens, URLs, and preview thumbnails. The phrase 'from one gallery preview page' clearly scopes the tool and distinguishes it from the sibling eh_get_all_gallery_pages.

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 scope 'from one gallery preview page' implies when the tool should be used, but there is no explicit guidance about alternatives or when not to use it. An agent must infer that eh_get_all_gallery_pages would be the choice for multiple preview pages.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: it states that the original-image URL is returned only 'when available' and lists navigation links and page keys as outputs. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It begins with the action and resource, then compactly lists the output components. Every clause 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 read-only, idempotent single-page resolution tool, the description covers the essential purpose and output semantics, and the output schema provides return-value details. The only meaningful gap is explicit routing guidance against gallery-page siblings, which is minor given the clarity of the rest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter (page, site, pageUrl) having its own description. The tool description adds no parameter-level detail, but the schema fully carries that burden, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Resolve') and clearly names the resource ('one E-Hentai image page') plus the expected outputs: displayed image URL, original-image URL when available, navigation links, and page keys. It is clear and distinct from gallery-level tools, though it does not explicitly name any sibling to differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the word 'one' — this tool resolves a single image page rather than a full gallery. However, the description does not explicitly explain when to prefer this over sibling tools like eh_get_gallery_pages or eh_get_all_gallery_pages, nor does it mention exclusions or alternative conditions.

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 adds useful behavioral context beyond the read-only/idempotent annotations by explaining that the selected site controls both the request and the base URL for relative gallery links. This is important for correctly interpreting returned URLs and is not derivable from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The primary purpose is stated first, the site-dependent URL behavior second, and the sibling routing last. 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 simple read-only tool with one optional parameter, a full enum, rich annotations, and an output schema, the description covers the essential operational nuance (site selection affecting URLs) and gives sufficient guidance 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?

The schema already documents the 'site' parameter fully with an enum and default. The description adds complementary meaning by explaining why the parameter matters: it controls both the request target and the base URL used for relative gallery links.

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 identifies the action ('List'), the resource ('current popular galleries'), and the two possible target sites. It distinguishes itself from eh_search_galleries by noting this returns the site's popular ranking rather than query-filtered results.

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 explicitly states when to use an alternative: 'Use eh_search_galleries when query filters are needed instead of the site's popular ranking.' This gives the agent a clear decision rule for choosing between this tool and its closest sibling.

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?

Annotations already mark it as read-only, idempotent, non-destructive, and open-world. The description adds the critical behavior that it requires no network request, which aligns perfectly with the annotations and provides additional clarity. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence conveys the full purpose and the key usage note (no network request). No wasted words.

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 zero parameters and a rich output schema, the description makes it clear what the tool does and that it's safe to call. The open-world hint implies the output changes based on state, but the description could explicitly state it returns static cached data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with zero parameters, so the description adds clear value by specifying what will be returned (categories, namespaces, qualifiers, operators, limits) without needing to document parameters.

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 specific verbs like "return" and lists concrete resources (categories, namespaces, qualifiers, operators, limits), clearly distinguishing this from sibling tools that perform search queries or fetch external data.

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 explicitly states that no network request is made, which helps agents decide not to use it when real-time data is needed. Adding when to avoid it or a brief alternative mention (e.g., none needed) would push it to a 5.

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?

Annotations already signal read-only and non-destructive behavior. The description goes beyond them by explicitly stating 'This tool never downloads a torrent,' which is a meaningful behavioral guarantee not fully implied by readOnlyHint. It also clarifies that it returns metadata and official .torrent links rather than torrent file contents.

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 two short sentences with no filler. It front-loads the core purpose and then supplies the most important behavioral caveat in the second sentence. Every part 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?

Given the strong annotations, fully self-describing input schema, and presence of an output schema, the description covers everything an agent needs to choose and invoke the tool correctly. It clarifies scope, behavior, and the key non-download guarantee without unnecessary detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already fully documented with types, defaults, formats, and mutual exclusivity. The description adds no additional parameter-level meaning, so it stays at the baseline rather than earning extra credit.

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 ('Read') and names a clear resource ('torrent metadata and official .torrent links'). It also adds a distinguishing detail by covering both current and outdated torrent metadata, which separates it from gallery metadata or search tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear the tool is for reading torrent metadata and links rather than downloading them, which establishes a useful boundary. It does not explicitly name alternative sibling tools or state when not to use it, but the torrent-specific focus provides clear context.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by warning that returned text is untrusted external content and must not be treated as instructions, which is critical for safe agent use.

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 two sentences with no filler: the first states the operation clearly, and the second delivers a concise but important security warning. 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 simple one-parameter read-only lookup tool, the description covers the core operation and the most important contextual risk (untrusted content). It could mention output shape or exact-match requirements, but given the simple schema and strong annotations, it is largely 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?

The schema already documents the only parameter 'tag' with the description 'Native E-Hentai tag name to look up', achieving full schema_description_coverage. The tool description does not add deeper parameter semantics, but it also does not need to because the schema is sufficient.

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 ('Read') and a clear resource ('structured tag definition from EHWiki'), which makes the tool's function immediately obvious. It also distinguishes itself from sibling tools like eh_search_translated_tags, which focus on searching rather than direct lookup of a tag definition.

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 what the tool does but provides no guidance on when to use it versus alternatives such as eh_search_translated_tags. There is no explicit mention of exact-match lookup or a scenario that should route an agent to this tool instead of a sibling.

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?

Annotations already cover read-only, idempotent, non-destructive behavior, while the description adds the concrete conversion behavior and accepted input forms. It does not discuss errors or edge cases like providing both page and pageUrl, but the schema handles those constraints and the safety profile is already established by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence states the input forms and the output with no wasted words. It gives the agent the essential purpose immediately without repeating schema details.

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 resolver with 100% parameter schema coverage, complete annotations, and an output schema, the description is sufficient. The agent has everything needed to select and invoke the tool correctly; return structure and parameter constraints are already captured in the structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description loosely restates the input choice between a URL and a page reference, but it does not add any parameter format, default, or constraint information beyond what the schema already 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 names a specific transformation: converting an image-page URL or page reference into a gallery ID and gallery token. It clearly identifies the verb, resource, and expected output, and it stands apart from sibling search and metadata tools.

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 clearly implies the tool should be used when an agent has an E-Hentai image-page URL or page reference and needs the owning gallery's ID and token. However, it does not explicitly mention alternatives such as eh_resolve_gallery_batch for multiple references or state when not to use this tool, so it stops short of full 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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: it preserves input order, preserves duplicates, and reports per-entry errors. This is exactly the kind of runtime behavior an agent needs to know before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the core action and scope, then adds the three most consequential behavioral guarantees. There is no filler, no repetition of schema details, and every clause 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 batch read-only resolution tool, the description together with the full schema, annotations, and output schema covers what the agent needs: input shape, bounds, ordering, duplicate handling, and error behavior. There is no major missing 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 100%, so the parameter semantics are fully documented in the schema. The description does not need to repeat parameter details, and it correctly adds no redundant parameter information. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Resolve'), a clear resource ('image-page references to gallery tokens'), and a bounded scope ('1-500'). The word 'batch' and the preservation semantics distinguish it from the singular resolve tool, even without naming it directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the intended use clear: resolve multiple image-page references in one call, with explicit batch sizing and preservation of order/duplicates/errors. It does not explicitly name the singular alternative 'eh_resolve_gallery' as the other option, but the batch context and sibling list make the selection obvious.

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?

Beyond the readOnly/idempotent annotations, it discloses that computation happens locally and the file is never uploaded, which is a meaningful privacy guarantee not inferable from schema or annotations. It also specifies exact-image search semantics. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core action and the most important behavioral constraint front-loaded. Every sentence adds value and there is no 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 a two-parameter tool with a full output schema, rich annotations, and complete schema descriptions, the description covers all essential selection and invocation information. The only slight gap is explicit routing to hash-based siblings, but that doesn't affect invocation correctness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains path as an absolute regular-file path and site as an enum with default. The description adds the local SHA-1 computation context, which helps clarify why the path is needed, but does not need to restate parameter details. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise action: read one absolute local file, compute SHA-1 locally, and perform exact image search. This clearly distinguishes it from sibling tools like eh_search_by_hash and other gallery-search tools. The 'file is never uploaded' detail further clarifies the local-file nature.

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 use when the agent has a user-selected absolute local file and wants an exact image match, and the schema reinforces path constraints. However, it doesn't explicitly name alternatives or state when not to use it (e.g., when a hash is already available, prefer eh_search_by_hash). Usage context is clear but exclusion guidance is absent.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side-effect expectations. The description adds the useful behavioral detail that no image upload occurs and requires an exact 40-character hash. It does not go deeper into rate limits, site behavior, or result handling, but given the strong annotation coverage, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the core purpose and includes a meaningful qualifier ('without uploading the image'). Every word carries weight; there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple hash-lookup tool with two well-documented parameters, rich annotations, and an output schema, the description is sufficient. The only minor gap is that it does not explicitly address the exhentai site option or clarify how results differ between sites, but the schema and output schema cover the operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters including the sha1 pattern and the site enum/default. The description restates the 'exact 40-character SHA-1 hash' concept already present in the schema, adding no substantial new semantic meaning. This meets the baseline for a fully schema-documented parameter set.

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 ('Search'), the target resource ('E-Hentai'), and the exact lookup key ('40-character SHA-1 image hash'). It also differentiates itself from file-upload search by emphasizing 'without uploading the image', which distinguishes it from sibling tools like eh_search_by_file.

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 proper usage context: use this tool when you already have an exact SHA-1 hash and do not need to upload an image. It does not explicitly name alternative tools or state when not to use it, but the 'without uploading the image' phrase provides meaningful contrast with file-upload-based search.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the context that this operates on the authenticated user's favorites (implying auth requirements) but discloses nothing about pagination depth, rate limits, or site-specific behavior beyond what the schema already reveals. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the action, resource, and search dimensions with zero filler. Every word earns its place and the most important scoping detail ('authenticated user's ... favorites') comes first.

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 output schema, rich annotations, and 100% parameter coverage carry most of the burden, and the description covers the core purpose adequately. The main gap is the absence of routing guidance among the many sibling search tools (eh_search_galleries, eh_search_watched, eh_search_translated_tags), which matters given the large and overlapping sibling set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions on all 6 parameters, so the baseline of 3 applies. The description groups parameters conceptually (query, category, cursor) which adds marginal organizational value but no syntax, format, or interaction details beyond what the schema already 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 uses a specific verb ('Search') with a clearly bounded resource ('the authenticated user's E-Hentai or ExHentai favorites') and names the search dimensions (native query, favorite category, cursor). This distinguishes it from siblings like eh_search_galleries (general gallery search), eh_search_watched (watched items), and eh_get_favorite_categories (category metadata).

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 'authenticated user's favorites' implies this is the destination for favorites-scoped searches, but the description never explicitly names alternatives or states when not to use it. With 29 siblings including several other search tools, the differentiation is left to inference 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?

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description only needs to add behavioral context beyond that. It explains that both E-Hentai and ExHentai are supported, that native syntax is expected, and that translated tag resolution is a prerequisite in some cases. This adds useful operational detail without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three focused sentences with the core purpose and filter scope in the first sentence, tag syntax guidance in the second, and the translation routing in the third. Every sentence earns its place and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the large parameter set and rich schema/output schema, the description covers the essential behavioral and syntactic context needed to invoke the tool correctly. It lacks explicit guidance on access restrictions for ExHentai and how this tool relates to query-building siblings, but the annotations and schema fill many gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the query-style nature of the tool, clarifying namespace-qualified tag format with concrete examples, and indicating that translated tags must be resolved beforehand. This goes beyond what the schema alone 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 clearly identifies the tool's action ('Search'), the resource ('E-Hentai or ExHentai galleries'), and the core mechanism ('native title and tag syntax'). It is specific enough to distinguish from hash/file-based searches, though it does not explicitly differentiate itself from several similarly named sibling search tools.

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 provides useful conditional guidance: use eh_search_translated_tags first for translated tag names, and pass native tags directly. However, it does not address when to choose this tool over siblings like eh_search_watched, eh_search_by_hash, or eh_search_favorites, so the guidance is partial.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds meaningful behavioral detail beyond annotations: the 10-page budget, deduplication of gallery references, and the resume-cursor behavior on truncation. These are not present in the annotations and materially shape how an agent should use the 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 a single, information-dense sentence. It front-loads the core purpose, then adds the key behavioral constraints and return behavior without wasted words. Every clause 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?

Given the presence of a detailed output schema, strong annotations, and 100% parameter schema coverage, the description covers the non-obvious contextual details: pagination limits, deduplication, cursor continuation, and metadata expansion avoidance. Nothing critical for correct invocation 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some context by explaining the 'page budget' and 'resume cursor', which maps to maxPages and next, but the parameter schemas already document those fields well. No significant gap requires the description to compensate.

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 a specific action ('Search'), resource ('galleries'), and scope ('up to 10 result pages'), while also naming distinctive behaviors: no metadata expansion, deduplication, and resume-cursor return. This distinguishes it from single-page search and metadata-focused sibling tools.

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 when to use the tool: for multi-page gallery searches with deduplication and cursor continuation. However, it never explicitly names alternatives such as eh_search_galleries or states when not to use this batch variant, leaving the routing decision somewhat inferred.

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?

While annotations already declare read-only, idempotent, and non-destructive behavior, the description adds important non-obvious semantics: galleryCount counts unique gallery uploads, uniqueWorkCount is heuristic, and every work carries a confidence level plus all source galleries. This prevents the agent from misinterpreting counts or treating merged works as true deduplicated entities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences communicate the full pipeline and the two key count semantics without redundant filler. The most important scoping information ('up to 10 result pages') is front-loaded.

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 13-parameter schema, full schema coverage, output schema, and strong annotations, the description is sufficient for an agent to understand the tool's high-level behavior and output quirks. It could be slightly more complete by explicitly mentioning pagination/truncation via the next cursor, but the schema and the 'up to 10 result pages' phrase cover the essentials.

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 covers 100% of parameters with descriptions, so the baseline of 3 applies. The description does not elaborate on individual parameters, but it clarifies output count semantics that relate indirectly to how aggregation behaves.

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 multi-step behavior: search up to 10 result pages, merge official version/language/upload variants into works, and group installments into series. This clearly communicates a gallery-work aggregation tool, though it does not explicitly compare itself with sibling search tools like eh_search_galleries.

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: choose this tool when you want aggregated 'works' and series rather than raw gallery results, and when up to 10 pages of scanning is acceptable. However, it never states when not to use it or names alternative sibling tools for raw gallery search or batch operations.

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?

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds non-obvious context: results include all matching candidates, no ambiguity resolution is performed, and returned data is subject to the source database license. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler; the core action is front-loaded, the output behavior follows, and the license caveat is kept to one clause. Every sentence contributes relevant 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 read-only lookup with two well-documented parameters and an output schema, the description is largely complete. The only notable gap is not mentioning when to use this tool versus the tag-definition sibling, but this does not 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?

Schema description coverage is 100%, so the schema already documents both 'query' and 'limit' clearly. The description's mention of Chinese/original English tag adds no parameter-specific meaning beyond what the schema provides, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Resolve'), a concrete input ('Chinese translated tag name or original English tag'), and a named source ('official EhTagTranslation database'). It also clarifies that it returns candidates and searchQuery fragments, but it does not explicitly distinguish this tool from the sibling eh_lookup_tag_definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than explicit: an agent can infer this is for obtaining native searchQuery fragments without resolving ambiguity, but the description gives no when-not-to-use guidance and names no alternatives such as eh_lookup_tag_definition.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by explicitly stating it 'never changes watched tags or account settings,' reinforcing the read-only nature in domain-specific terms.

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 two sentences with no wasted words. The primary action and resource are front-loaded, and the safety reassurance is kept brief and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, output schema, and strong annotations, the description is mostly complete for a read-only feed search tool. It could be stronger by explicitly naming sibling alternatives or saying when not to use it, but overall it provides sufficient high-level context for an agent to select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 14 parameters in detail. The description adds a high-level grouping ('native search, category, advanced-filter, and cursor controls') but does not need to explain individual parameters because the schema handles that burden.

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: 'Read the authenticated user's watched-tag gallery feed' with search, category, advanced-filter, and cursor controls. This clearly distinguishes it from sibling tools like eh_search_galleries and eh_search_favorites by naming the watched-tag feed as the target.

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 usage context: use this tool to read and filter the watched-tag gallery feed. However, it does not explicitly state when to choose this tool over alternatives such as eh_search_galleries or eh_search_favorites, nor does it mention exclusions.

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