Skip to main content
Glama
smeet666

mcp-rule34

mcp-rule34

npm CI license

Ein MCP-Server für rule34.xxx. Durchsuche die Posts der Seite per Tag über ihre eigene API und erhalte für jeden Post die zugehörige Seite, seine Datei, seine Abmessungen, seinen Score, sein Rating und seine vollständige Tag-Liste, zusätzlich zur Anzahl der Posts, die die gesamte Suche findet.

Dieser Server benötigt Anmeldedaten. rule34.xxx vergibt einen API-Schlüssel pro Konto, und die Bedingungen der Seite erlauben automatisiertes Lesen nur über diese API. Einen Schlüssel zu bekommen, dauert eine Minute und wird unter Konfiguration beschrieben.

(Version française plus bas / Französische Version weiter unten)


Schnellstart

Claude Code

claude mcp add rule34 --env RULE34_USER_ID=your-id --env RULE34_API_KEY=your-key -- npx -y mcp-rule34

Claude Desktop, Cursor und jeder Client, der das Standard-Konfigurationsformat verwendet

{
  "mcpServers": {
    "rule34": {
      "command": "npx",
      "args": ["-y", "mcp-rule34"],
      "env": {
        "RULE34_USER_ID": "your-id",
        "RULE34_API_KEY": "your-key"
      }
    }
  }
}

Lege dies in deiner Benutzer-Konfiguration ab und nicht in einer Projektdatei: Eine .mcp.json im Wurzelverzeichnis eines Repositorys wandert mit dem Repository, und der Schlüssel wandert ebenfalls mit.

Related MCP server: Civitai MCP Server

Konfiguration

Variable

Was sie ist

Standard

RULE34_USER_ID

Deine numerische Konto-ID. Erforderlich.

—

RULE34_API_KEY

Dein API-Schlüssel. Erforderlich, persönlich.

—

RULE34_MIN_INTERVAL_MS

Millisekunden zwischen zwei Requests.

1000, niemals weniger

RULE34_TIMEOUT_MS

Wie lange ein Request dauern darf.

20000

RULE34_MAX_RETRIES

Versuche nach dem ersten, bei vorübergehenden Fehlern.

3

RULE34_CACHE_TTL_MS

Wie lange eine Antwort im Speicher bleibt.

300000

RULE34_CACHE_MAX_ENTRIES

Wie viele Antworten im Speicher bleiben.

300

RULE34_USER_AGENT

Überschreibt den Agenten, den dieser Client sendet.

mcp-rule34/<version> (+…)

RULE34_LOG_LEVEL

silent, error, info oder debug, auf stderr.

error

Wo die Anmeldedaten herkommen. Melde dich an, öffne die Account-Optionen und suche die Zeile API Access Credentials. Sie zeigt &api_key=…&user_id=…; diese beiden Werte sind, was in die obige Konfiguration gehört. Ist der Schlüssel leer, anklicke Generate New Key? und speichere.

Die Seite vergibt einen Schlüssel pro Person and verlangt, dass Anwendungen, die ihren Inhalt ausliefern, keine Werbung zeigen und keinen Numberation dahinterstellen. Dieser Server hat keinen eigenen Schlüssel; jeder Nutzer bringt seinen eigenen mit.

Ein Server, der ohne Anmeldedaten gestartet wird, startet trotzdem, veröffentlicht sein Werkzeug und beantwortet jeden Aufruf, indem er die beiden zu setzenden Variablen nennt. Er sendet nie einen Request, von dem er weiß, dass die Seite ihn ablehnt.

Werkzeuge

Tool

Was es tut

Wichtige Parameter

search_posts

Findet Posts, die einen Tag oder mehrere tragen.

tags, any_of, exclude, media_type, rating, sort, limit, page

get_post

Liest einen Post vollständig, mit einer Art für jeden Tag.

id, url

Die Suche benennt Posts, eine Fiche liest sie vollständig

Ein Post auf rule34.xxx trägt im Median etwa zweihundert Tags, einige tragen neunhundert. Ein Bezüge für zwanzig Ergebnisse, bei der Benn jeder Tag ausgeschrieben ist, würde vier Fünftel ihrer Antwort für Tag-Strings aufwenden, die niemand liest; deshalb zeigt eine Suchzeile die ersten zwölf und angibt, wie viele Tags der Post insgesamt trägt.

get_post liest einen Post anhand seiner ID oder über einen Link auf seine Seite und gibt jeden Tag mit vollständiger Art zurück – Character, Copyright, Artist, General oder Metadata – sowie wie viele Posts ihn teilen; dazu die Angaben des Uploaders, die Zahl der Kommentare und das Veröffentlichungsdatum. Ein Link wird gelesen nicht verfolgt: Dieser Server baut seine eigenen Request aus der ID, die er darin findet.

Einen Post zu lesen need zwei Requests, denn keines der Formate, das die API veröffentlicht, trägt alles: Das Veröffentlichungsdatum kommt aus dem einen, der Name des Uploaders, die Kommentarzahl und die Tag-Kategorien aus der anderen.

Tags sind einzelne Tokens

rule34.xxx speichert einen Tag als ein einziges Token und verbindet mit Unterstreichen der Wörter, die ein mensch als Wörter sagt. asuka langley sohryu bleibt das asuka_langley_sohryu derselbe Tag, und dieser Server schreibt aus dem ersten das zweiten. Interpunktszeichen innerhalb einem Namen, die ihm angehören: Der Serien-Tag ist ranma_1/2, inklusive Schr.

Drei Listen, drei Fragen

{
  "tags": ["asuka langley sohryu", "black hair"], // every one of these
  "any_of": ["blonde hair", "red hair"], // at least one of these
  "exclude": ["monochrome", "3d"], // none of these
}

Filter liegen in eigenen Argumenten vor, nicht in den Tags, und die Antwort kann das Rating und die Sortierung angeben, die tatsächlich verwendet wurden.

Bilder, Animationen oder Videos abfragen

media_type akzeptiert image, animated, video oder any. rule34.xxx trägt die Unterscheidung in seinen eigenen Tags, also filtert die Seite die Ergebnisse selbst, und gezählt wird, was erfragt wurde. Die Klassifizierung ist deshalb so gut wie die Tagging von selber Seite.

Farbigkeit wird durch Abwesenheit ausgedrückt: Die Seite tagt das, was schwarz-weiß ist, und markiert nichts als farbig. Frage farbig ab mit "exclude": ["monochrome", "greyscale", "grayscale"].

Ratings

Die Seite und zwei Ratings: questionable und explicit. Fragt man rule34.xxx nicht nach safe, general oder sensitive, erhält man null Posts und keinen Fehler – das liest sich als eine Abwesenheit und nicht als ein Rating, das die Seite nie hatte. Deshalb lehnt dieser Server Diese drei Einstellungen ab, statt sie weiterzugeben.

Memory, das if

Ein Tag, der nicht existiert, leert die Suche genauso wie eine Kombination, für diese die Seite nichts hält. Wenn eine Suche nach mehreren Tags leer zurückkommt, fragt dieser Server die site, welche der Namen sie kennt, und die Antwort sagt, welche sie nicht kennt:

No post on rule34.xxx matches neon_genesis_evangelion asuka_langley_sohry.

Note: rule34.xxx holds no tag named 'asuka_langley_sohry'. A tag that does not
exist empties a search on its own.

Was eine Antwort aussagt

Aus jeder Antwort: die Gesamtzahl, die die Seite für the ganze Suche ermittelte, die ausgelieferte Seite und die Suche, wie sie in der Sprache der Seite gesendet wurde. Ein Post trägt seine rule34.xxx-Seite, seine Datei, seine Thumbnail, seine Abmessungen, seinen Score, sein Rating, seine Tags, was der Uploader als Quelle angegeben hat, und das Datum Veröffentlichungs.

Bei einem Post existieren zwei Daten, und nur eine davon ist das Veröffentlichungsdatum: Ein Post, der 2016 zuerst hochgeladen und letzte Frühjahr neu getagant wurde, trägt beide, und diesen Server gibt die erste an.

Was dieser Server nicht tut

Er lädt nichts hoch, gibt keine Stimmenabgabe, no Kommentare und schreibt nichts auf rule34.xxx.

Fehler

Jeder Fehler trägt genau eine Codes genannt, und der Code eröffnet die Meldung: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.

rate_limited bedeutet, dass die site diesen Current gerade abweist, und nie Sachen, die Suche habe Ecke Resultate gefunden. rule34.xxx begrenzt seine Rate, ohne zu veröffentlichen, was die Rate ist; deshalb stellt dieser Client eine Frage nach der anderen, mit secondene zwischen zwei Requests, die keine Konfiguration verkürzen kann, und zieht sich weiter zurück, wenn die page Widerstand leistet.

En tant que bibliothèque

Die Leseschicht wird ohne das Protokoll separat veröffentlicht:

import { Rule34Client } from "mcp-rule34/client";

Sie bringt dieselbe Taktung, denselben Cache und dieselbe Fehlerbuchführung mit.

Anforderungen

npm install
npm test          # unit tests, no network
npm run typecheck
npm run check     # biome and prettier
npm run build

Eine Live-Suite erreicht das Nachrichtenseite und läuft nur, wenn Anmeldedaten einstehen:

RULE34_USER_ID=… RULE34_API_KEY=… npm run test:live

License

MIT.


mcp-rule34 (français)

Ein MCP-Server für die rule34.xxx. Durchsucht die Posts der Seite per Tag über ihr API, und gibt aus: je jeweils kennt, Seite, Datei, Abmessungen, Score, Rating und alle Tags plus die Anzahl der Posts, die die ganze Suche findet.

Dieser Server benötigt Anmeldedaten. rule34.xxx vergibt einen API-Schlüssel per Konto, und die Seite erlaubt automatisiertes Lesen nur über API. Einen Key zu erhas du in einer Minute, siehe oben Befähigungskonfiguration.

Démarrage

Claude Code

claude mcp add rule34 --env RULE34_USER_ID=votre-id --env RULE34_API_KEY=votre-clé -- npx -y mcp-rule34

Claude Desktop, Cursor, und alle Clients ja Standard-Format

{
  "mcpServers": {
    "rule34": {
      "command": "npx",
      "args": ["-y", "mcp-rule34"],
      "env": {
        "RULE34_USER_ID": "votre-id",
        "RULE34_API_KEY": "votre-clé"
      }
    }
  }
}

Das legst du in deiner Benutzer-Konfigurationsdatei ab und nicht in einer Projektdatei: ein .mcp.json in der Repositorystammrunde reist trägt mit dem Repo, und der Schlüssel reist mit.

Konfiguration

Variable

Was sie ist

Standard

RULE34_USER_ID

Die numerische Konto-ID. Erforderlich.

—

RULE34_API_KEY

Der API-Schlüssel. Erforderlich, persönlich.

—

RULE34_MIN_INTERVAL_MS

Millisekunden zwischen zwei Anfragen.

1000, niemals darunter

RULE34_TIMEOUT_MS

Dauer eines Requests.

20000

RULE34_MAX_RETRIES

Nach der ersten bei transient failure.

3

RULE34_CACHE_TTL_MS

Haltbarkeit einer Antwort im Kopf.

300000

RULE34_CACHE_MAX_ENTRIES

Anzahl der Antworten, den memorisiert bleiben.

300

RULE34_USER_AGENT

Ersetzt den Agenten des Clients.

mcp-rule34/<version> (+…)

RULE34_LOG_LEVEL

silent, error, info oder debug, auf stderr.

error

Anmeldedaten bekomme so: einloggen, dann Kontooptionen öffnen und API Access Credentials suchen. Sie zeigt &api_key=…&user_id=…, das sind die Werte für die Konfiguration oben. Wenn der Schlüssel leer, aktivieren Sie Generate New Key? und speichern.

Die Seite gibt einen Schlüssel pro Person aus und ein net ning Applications, die ihre Inhalten zeigen, display keine Werbung schreibt nicht in hinter Zahlsperren. Dieser Server hat keinen eigenen Schlüssel, also bringt jede Nutzung ihren eigenen mit.

Ein Server, der ohne Zugangsdaten startet, startet durch drei, veröffentlicht sein Werkzeug und beantwortet jeden Anruf mit den Namen der beiden Variablen. Er reicht nie unpassed that er weiß, dass site ableckt.

Werkzeuge

Tool

Es tut

Eigentliche Parameter

search_posts

Findet Posts mit einen Tag oder oder gleichzeitig mehrere.

tags, any_of, exclude, media_type, rating, sort, limit, page

get_post

Liest einen Post ganz, mit the type for each tag.

id, url

Die Suche nennt Beiträge, die Scharte liest sie ganz

Ein Beitrag zu Regel 34.34 trägt eine mittlere Zahl около two hundred tags, and some trägt new hundred neunhundert. Eine Seite mit zwanzig Treffer, wo jeder Tag ausgeschrieben ist, kommt noch ein viertel die vier Fünftel seiner Antworten für Tag-Strings verwenden. Deshalb zeigt die Searchzeile die first zwölf und sagt, wie viele de Tag insgesamt nummer hat.

get_post liest einen Post anhand seiner ID oder über einen Link zu seiner Seite aus und gibt jeden Tag mit seiner Kategorie zurück – Charakter, Copyright, Künstler, Allgemein oder Metadaten – sowie die Anzahl der Posts, die ihn teilen, mit dem Hochladenden, der Anzahl der Kommentare und dem Veröffentlichungsdatum. Ein Link wird ausgelesen und nicht verfolgt: Dieser Server baut seine eigene Anfrage aus der darin gefundenen ID.

Das Lesen eines Eintrags kostet zwei Anfragen, weil keines der beiden von der API veröffentlichten Formate alles trägt: Das Veröffentlichungsdatum stammt aus dem einen, der Name des Hochladenden, die Anzahl der Kommentare und die Tag-Kategorien stammen aus dem anderen.

Ein Tag ist ein einziges Wort

rule34.xxx legt einen Tag als ein einzelnes Wort ab, indem starting list compressed persons various in several succeeded circle to a connected line. asuka langley sohryu und asuka_langley_sohryu sind derselbe Tag, und dieser Server schreibt den zweiten aus dem ersten. Die Zeichensetzung eines Namens gehört ihm selbst: Der Tag der Serie ist ranma_1/2, Schrägstrich eingeschlossen.

Drei Listen, drei Fragen

{
  "tags": ["asuka langley sohryu", "black hair"], // tous ceux-là
  "any_of": ["blonde hair", "red hair"], // au moins un de ceux-là
  "exclude": ["monochrome", "3d"], // aucun de ceux-là
}

Die Filter leben in ihren eigenen Argumenten statt in den Tags, sodass eine response angeben kann, welche Klassifikation und welche Endsorterung sie tatsächlich angewendet hat.

Bilder, Animationen oder Videos anfordern

media_type akzeptiert image, animated, video oder any. rule34.xxx trägt die Unterscheidung in seinen eigenen Tags, also Sie die Website, filtert, und the Gesamtsumme, die sie zurückmeldet, spricht genau das Angebot aus. Die veg pricing therefore only as gut as the work of its contributors.

Farben werden durch eine Absenz dargestellt: Die Website taggt Schwarzweiß und taggt nichts, wenn ein Post cutting edge von Werte ist. Fragen Sie Farben with "exclude": ["monochrome", "greyscale", "grayscale"] ab.

Die Klassifikationen

Die Website unterhält drei Klassifikationen: questionable und explicit. Auf rule34.xxx den Wert safe, general oder sensitive abzufragen, keine Outposts und keinen Fehler liefert – das beleuchtet sich eher als Abwesenheit, denn als Klassifikation, die hard site nie hatter. Daher verwendet dieser Server from these Wortfeldernvektors instead, through then verify.

Wenn eine Suche nichts findet

Ein Tag, der nicht existence, sorgt headtheo Suche genau so empty aus wie eine Kombination, von der die Website nothing total. Wenn Mehrfach-Tag-Suche leer zurückkommt, fragt dieser Server die Website, welche dieser Schein für sie kennt, und die viewer nennt the Nametag known to them who she does not know.

Was eine Antwort enthält

Jede Antwort trägt die Summe, die die Website für die gesamte Suche gezählt hat, die ausgerichtete Seite und die Anfrage, wie sie in der Sprache der Website gesendet wurde. Ein Post enthält seinen rule34.xxx-Seite, seine Datei, seine Vorschaubild, sein Bemaßungen, seinen Punkte, seinen Klassifikation, inserting sprite with tags?, devenues Quelle credited by nach Richtung erhältlich, falls cycle and has data new VERÖFF.

Ein Post trägt zwei Daten, und nur eines davon ist das Veröffentlichungsdatum: Ein Bild, das 2016 hochgeladen und im letzten Frühjahr neu getaggt wurde, trägt be legitimate, dy server handles the first.

Was dieser Server nicht tut

This blog doesn't have upload anything, doesn't stimulate anything, doesn't compress anything, and writes nothing to rule34.xxx.

Die Fehler

Jede Störung trägt einer von zugriff Codes, and the code indicates des Nachricht: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.

rate_limited bedeutet, dass die Website vient Ebene: diesen Client den Moment ablehnt, und not that a ssearch offsprings nothing found. rule34.xxx drossült sein Ratenco, ohne zu veröffentlichopen; deshalb you asked every be ratio all to once, separatized by einer Sekunde, that compress can and efileblock. Extends reif when er sich selbstverständlichen.

Als Bibliothek verwendbar

Die Leseschicht ist golden alone, ohne Protokoll:

import { Rule34Client } from "mcp-rule34/client";

She trägt dasselben fiction, dieselbe Cache und dieselbe Error-Taxonomie.

Entwicklung

npm install
npm test          # tests unitaires, sans réseau
npm run typecheck
npm run check     # biome et prettier
npm run build

Eine Suite und Sonnange commands: the Website director.

RULE34_USER_ID=… RULE34_API_KEY=… npm run test:live

Lizenz

MIT.

Available Tools

3 tools
find_tagsFind how a tag is spelledA
Read-onlyIdempotent

Find how rule34.xxx spells a tag, and how many posts carry it. The site matches from the start of a name, so 'kimagure' finds 'kimagure_orange_road' while 'orange road' finds nothing. It offers at most ten names. Use this before searching when a name might be spelled differently, and after a search that found nothing because a tag does not exist.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe start of a tag name, such as 'kimagure' or 'prince of tennis'. Spaces are joined with underscores.

Output Schema

ParametersJSON Schema
NameRequiredDescription
tagsYes
notesYes
queryYesThe text as rule34.xxx would spell it.
sourceYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavior beyond those: prefix matching ('matches from the start of a name'), the ten-result limit, and that it returns the spelling and post count. 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.

Conciseness5/5

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

Three sentences, no fluff. The main purpose is front-loaded, followed by a concrete matching example, then usage guidance. Every sentence serves a distinct role and the description is appropriately sized for the tool's simplicity.

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

Completeness5/5

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

With an output schema present (so return values are documented elsewhere) and the single parameter fully described in the schema, the description covers all remaining contextual needs: when to use, how matching works, result limit, and how it relates to searching. Nothing an agent needs to call it correctly is missing.

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?

The input schema's 'query' property description already fully covers the parameter semantics: 'The start of a tag name... Spaces are joined with underscores.' The tool description provides an illustrative example ('orange road' finds nothing) but does not add new parameter-level meaning beyond the schema, which has 100% coverage. Baseline 3 is appropriate.

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

Purpose5/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 precise resource ('how rule34.xxx spells a tag, and how many posts carry it'). It clearly differentiates from sibling tools (search_posts, get_post) by focusing on tag spelling and post count rather than post content or retrieval.

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

Usage Guidelines5/5

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

Explicitly instructs when to use: 'Use this before searching when a name might be spelled differently, and after a search that found nothing because a tag does not exist.' This gives clear context and ties to search_posts, and also notes the 'at most ten names' limitation.

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

get_postRead one postA
Read-onlyIdempotent

Read one rule34.xxx post, named by its id or by a link to its page. Returns every tag the post carries, each with its kind (character, copyright, artist, general or metadata) and how many posts share it, alongside the image or video, the dimensions, the score, the rating, the uploader, the number of comments, the credited source and the date the site took the post in. Use this after a search, whose rows show only the first few tags of each post.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoThe post's numeric id, as a search returns it.
urlNoA link to the post's page, such as https://rule34.xxx/index.php?page=post&s=view&id=2195419. The link is read rather than followed.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYes
md5Yes
tagsYes
notesYes
ownerYesThe account that uploaded the post.
scoreYesThe site's own score, updated once a day.
widthYes
heightYes
ratingYes
sourceYes
statusYes
file_urlYes
post_urlYes
has_notesYes
parent_idYes
changed_atYesWhen the post last changed, ISO 8601.
created_atYesWhen the post was added to rule34.xxx, ISO 8601. The site imported much of its older catalogue in bulk, so thousands of posts share one day.
sample_urlYes
preview_urlYes
source_siteYes
comment_countYes

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses detailed behavior: it returns every tag with its kind and post count, media type, dimensions, score, rating, uploader, comment count, source, and ingestion date. It also clarifies that a URL link is 'read rather than followed,' which is useful behavioral nuance not present in 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.

Conciseness4/5

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

The description is front-loaded with the core action and identifier modes, then lists returned data, then gives usage context. It is a single long sentence with a dense enumeration, but each element carries information and nothing is filler. Minor redundancy with the title and output schema keeps it from a 5.

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

Completeness5/5

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

Given the rich output schema, strong annotations, and sibling context, the description covers what the agent needs to know: when to invoke (after a search), how to identify the post (id or URL), and what behavior to expect (read-only, URL not followed). No critical decision-making information is missing.

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

Parameters4/5

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

The input schema already documents both parameters well (100% coverage), but the description adds meaning by framing them as equivalent alternatives: 'named by its id or by a link to its page.' This compensates for the schema's lack of an explicit oneOf constraint, though the description could have been even more explicit about exactly-one semantics.

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

Purpose5/5

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

The description states a specific verb ('Read'), a single resource ('one rule34.xxx post'), and the two ways to identify it ('id or link'), which clearly distinguishes it from the sibling search_posts and find_tags tools. It also names exactly what the tool returns, so there is no ambiguity about its function.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this after a search, whose rows show only the first few tags of each post,' giving clear when-to-use context versus search_posts. It does not explicitly enumerate when not to use it or mention find_tags as an alternative, but the single vs. search distinction is reasonably clear.

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

search_postsSearch posts by tagA
Read-onlyIdempotent

Search rule34.xxx for posts carrying a tag, or several tags at once. Tags are written as one token, so a name said as words is joined by underscores: 'asuka langley sohryu' and 'ranma 1/2' are single tags, and this tool joins them for you. Returns each post's page, its image or video URL, dimensions, score and rating, alongside the number of posts the whole search matches. A row shows the first 12 of a post's tags and says how many it has; call get_post for the whole list with a kind for every tag. Use 'media_type' to ask for still images, animations or video; the site classifies these itself. When a search finds nothing, the answer names the tags rule34.xxx does not hold, or says how many posts the tags match once the restrictions are dropped.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
sortNo'score' is the site's own tally of votes, recomputed once a day. 'id' is newest first. 'updated' is by when a post last changed, which retagging moves. 'random' draws a different set on each call.score
tagsYesTags a post must all carry, such as ['asuka langley sohryu', 'black hair'].
limitNo
any_ofNoTags a post must carry at least one of.
ratingNoThe two ratings rule34.xxx holds. Leave unset to search both.
excludeNoTags a post must not carry, such as ['monochrome'] to leave out black and white.
media_typeNo'image' for stills, 'animated' for GIFs, 'video' for MP4. The site states this in its own tags, so the classification is as good as the tagging.any

Output Schema

ParametersJSON Schema
NameRequiredDescription
pageYes
tagsYesThe required tags, as rule34.xxx spells them.
notesYes
postsYes
queryYesThe search as it was sent, in the site's own language.
totalYesPosts the whole search matches, as counted by the site.
any_ofYesThe alternatives, as rule34.xxx spells them.
sourceYes
excludeYesThe excluded tags, as rule34.xxx spells them.
has_moreYes
next_pageYes

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses what each result row contains, how many tags are shown, total match count, and the exact behavior when no results are found. These details meaningfully exceed the annotations, which already mark the tool as read-only and idempotent.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: scope, tag formatting, return contents, sibling routing, media_type nuance, and empty-result behavior. It is front-loaded with the core action.

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

Completeness5/5

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

For an 8-parameter search tool, the description covers input formatting, output shape, pagination-relevant count, media filtering, and failure behavior. Since an output schema exists, nothing essential is missing for an agent to call the tool correctly.

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

Parameters4/5

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

With 75% schema coverage, the schema already documents most parameters. The description adds real value by explaining that multi-word tags are underscore-joined and that the tool performs the joining, and by clarifying that media_type relies on the site's own tagging.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Search rule34.xxx for posts carrying a tag, or several tags at once.' It also distinguishes itself from the sibling get_post by telling the agent to call get_post for a post's full tag list.

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

Usage Guidelines4/5

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

It gives an explicit hand-off to get_post for the complete tag list, and explains when media_type should be used. It does not mention find_tags as an alternative, but the core search use case is unambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.0.1
    • Changedget_post12 fields changed
      • removedOutput schema / properties / changed_at / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / changed_at / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / created_at / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / created_at / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / owner / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / owner / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / preview_url / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / preview_url / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / sample_url / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / sample_url / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / source / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / source / type
        Added value: +[
        +  "string",
        +  "null"
        +]
    • Changedsearch_posts8 fields changed
      • removedOutput schema / properties / posts / items / properties / created_at / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / posts / items / properties / created_at / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / posts / items / properties / preview_url / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / posts / items / properties / preview_url / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / posts / items / properties / sample_url / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / posts / items / properties / sample_url / type
        Added value: +[
        +  "string",
        +  "null"
        +]
      • removedOutput schema / properties / posts / items / properties / source / anyOf
        Removed value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "type": "null"
        -  }
        -]
      • addedOutput schema / properties / posts / items / properties / source / type
        Added value: +[
        +  "string",
        +  "null"
        +]
  2. 3 tool updatesv1.1.0
    • First observedfind_tags
    • First observedget_post
    • First observedsearch_posts

TDQS

A4.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search_posts queries by tags, get_post retrieves one post's full details, and find_tags resolves tag spellings. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow the same verb_noun pattern: search_posts, get_post, find_tags. The naming is predictable and consistent, making it easy for an agent to infer what each tool does.

Tool Count5/5

Three tools is an appropriate scope for a focused rule34.xxx client: find tags, search posts, and inspect a single post. Each tool earns its place and there is no unnecessary bloat.

Completeness5/5

The tool set covers the core user workflow end to end: discovering the correct tag, searching posts with filters, and retrieving complete post metadata. No obvious missing operation is needed for the server's stated purpose.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    F
    maintenance
    Enables searching and analyzing Danbooru tags, character statistics, and wiki information. Extracts tags from posts, analyzes frequently used tags for characters with customizable filters, and retrieves detailed wiki entries.
    1
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with the Civitai API to search for AI models, browse images, and access creator information. It provides tools for filtering models by popularity, rating, or type and retrieving detailed version metadata.
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Searches Danbooru for anime/game characters and their associated tags, providing tools to retrieve character profiles, co-occurring tags, wiki descriptions, and tag implications.
    5
    12
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables semantic search of Danbooru tags using natural language queries to generate precise prompts for anime-style image generation.
    7
    MIT