Skip to main content
Glama

Find similar galleries

eh_find_similar_galleries
Read-onlyIdempotent

Find similar E-Hentai or ExHentai galleries by extracting a structural title for exact quoted search, then falling back to the first artist tag or uploader when no title remains.

Instructions

Find galleries using EhViewer's strategy: extract a structural title and run an exact quoted search, falling back to the first artist tag and then the uploader when no title remains.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNoTarget site; gallery URLs override this when a URL is providede-hentai
galleryNoGallery ID and token; provide this or galleryUrl, but not both
galleryUrlNoFull gallery URL; provide this or gallery, but not both

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.0
    • addedOutput schema / properties / result / properties / result / properties / galleries / items / properties / site
      Added value: +{
      +  "enum": [
      +    "e-hentai",
      +    "exhentai"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / result / properties / result / properties / galleries / items / required
      Previous value: -[
      -  "gid",
      -  "token",
      -  "url",
      -  "title",
      -  "category",
      -  "uploader",
      -  "posted",
      -  "pages",
      -  "rating",
      -  "tags",
      -  "thumbnailUrl"
      -]New value: +[
      +  "gid",
      +  "token",
      +  "site",
      +  "url",
      +  "title",
      +  "category",
      +  "uploader",
      +  "posted",
      +  "pages",
      +  "rating",
      +  "tags",
      +  "thumbnailUrl"
      +]
  2. Changed3 schema fields changedv0.1.2
    • addedInput schema / properties / gallery / description
      Added value: +"Gallery ID and token; provide this or galleryUrl, but not both"
    • addedInput schema / properties / galleryUrl / description
      Added value: +"Full gallery URL; provide this or gallery, but not both"
    • addedInput schema / properties / site / description
      Added value: +"Target site; gallery URLs override this when a URL is provided"
  3. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds real behavioral value by disclosing the internal fallback chain: structural title extraction, then exact quoted search, then artist tag, then uploader. It does not mention whether the source gallery appears in results or how many results are returned.

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

Conciseness4/5

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

A single dense sentence that front-loads the purpose and then the mechanism; no filler. 'EhViewer's strategy' is mildly jargon-y, but the following clause explains it, so nothing is wasted.

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

Completeness3/5

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

With annotations covering safety and an output schema covering returns, the remaining gap is routing guidance: this tool sits among many search siblings and the description never says when it beats them. For a derived-similarity tool in a crowded namespace, that omission leaves the definition merely adequate.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents site, gallery, galleryUrl, and the mutual-exclusion note. The description adds no parameter-level detail beyond what is in the schema, so the baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb (find) and resource (similar galleries) and even names the algorithm family (EhViewer's strategy), which distinguishes it from generic search siblings like eh_search_galleries. It is slightly weaker on stating that the input is a source gallery (gid/token or URL) rather than free-text terms.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as eh_search_galleries. The similarity intent is implied by the word 'similar', but the agent must infer the routing decision itself.

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