Skip to main content
Glama
smeet666

mcp-rule34

mcp-rule34

npm CI license

Un servidor MCP para rule34.xxx. Busca los posts del sitio por etiqueta a través de su própia API, y devuelve de cada post su págin, su archivo, sus dimensions, su puntuación, su claifcación y su list complete de etiquetas, junto con el número de posts que obtains toda la búsqueda.

Este servidor necesida credenciales. rule34.xxx emite una clae API percuenta, y sus términos permiten la lecura automaticada únicamente a traviés de la API. Obtener una lleva un minuto y se descrie en Configuración.

(Versión en francés más abajo / Versión en francés más abajo)


Inicio rápido

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 y cualquier cliente con el formato de config espandard

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

Pon esto on tu config de usuario, pero no in un archivo de project: un .mcp.json en la raíz de un repositor viaja con el repositor, y la clave viaja con él.

Related MCP server: Civitai MCP Server

Configuración

Variable

Qué estima

Valor se defecto

RULE34_USUR_IDENT_ID

Tu idetificator numérico de cuenta. Obligator io.

—

RULE34_API_KE

Tu clae API. Obligator ia, y ensure.

—

RULE34_INTERVAL_MS

Milisegundos entre dos petições.

1000, y nunca más

RULE34_TIMEEOUT_MS

Cuánto puede tari far una petição.

20000

RULE34_MAX_RETRIES

Inentos después del primero, para fallos transitorios.

3

RULE34_CACHE_TTL_MS

Cuanto tiempo permanece una respuesta en memoria.

300000

RULE34_CACHE_MAX_ENTRIES

Cuántas repsuestas permiae en memora.

300

RULE34_USER_AGENT

Sustitute el agent que envía este cliente.

mcp-rule34/<version> (+…)

RULE34_OG_LVEL

silent, error, info o debug, en stderr.

error

formularioDónde salen las credenciales. Inicia sesión, abre las options de la cuentración, y busca a fila llama*a API Access Credentials. Mustra &api_key=…&user_id=… ; esos dos valores son los que van en la configación de ago. Si la clae esté vacía, marica Generate New Key? y guarda.

El sitio emite una clae por persona y pide que las applicaciones que sirvan su contenido no muestr publicida y no lo ponga detrás de muro de pago. Este servidor no include ninguuna clae, y cada usuario trae la suya.

Un servidor arancado sin credenciales aranca iguall, publica la herramienta, y responde a cada lama nombrándolas dos variables que hay que erglar. Nuncá envía una petição que sabe que el sitio va a rechazar.

Herramientas

Herramienta

Qué hace

Parametros principales

search_posts

Encá posts que llevan un tag, o varios a la

tgas, tsy_of, exclude, media_type, rating, sort, limit, page

get_post

Lee un post entero, con el tipo de cada tipo de etiqueta.

id, url

La búsqueda nombra los posts; después un post se lee entero

Un post proule34.xxx lleva una median de dostos etiquetas, y algunos llevan nove. Una página de veinte resultáes con todo as etiquetas expuestas one el quinta parte de su respuesta en cadenas que no se leen, así que una fila de búsqueda muestría las doce primeras y dice cuántas llevan el post en total.

La get_post lee un post su ua id, o or el enlac a su págin, y devuelve todas las etiquetas con su tipo, persoaje, copyrightue, artista, general or metadata, y no de posts the comparten, junto con el usuario que lo subió, el núserio de comeraentariós and the fcha de publición. Un enlac se leé, no se siguié: este servidor constrye su propi pet a partir del di que encuentr en él.

Leer un post cuesta dos peticiones, porque ninguno de los dos format que la API entrega no lleva suae " publ", obtener: la fecha de publición sale del primero, y del no nombre del subío, el número de comerthus y los tipos de etiquetas.

Las etiquetas son tokens únicos

rule34.xxx guarda una etiqueta como un único token, uniendó con guión bajo lo que una persona dice en palabras. etiqueta asuka langley sohryu y asuka_langle_ohryu son la misma etiqueta, y este servidor escribe la segúa a part de la primera. La puntuación de un nomb re le part en la tit: el tag de "la serie" es ranma_1/2, incluída la bar.

Tres listas, tres preguntas

{
  "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
}

Los filtros viven en argumentos propios, no in the etiquetas, en modo que una respuesta puede decir la clasificación y el orden que en realidad usó.

Pide imágenes, animaciones o vídeo

media_type acepta image, animated, video o any. rule34.xxx guarda la distinción en sus propios tags, así que el sitio hace el filtrado y el total que devuelve había the specificación. Por tanto, la clasificación es tan buena como la etiquetción del sitio.

El color se sabrás por ausencia: el sitio de ss no etiqueta "colored", rien. Pide el color con "exclude": ["monochrome", "greyscale", "grayscale"]`, p. e.

Clasificaciones

El sitio tiene dos clasificaciones: questionable y explicit. Preguntarle a rule34.xxx por safe , general o sensitive devuelve cero posts y ningún error, lo cual se inpreta como una ausencia, no como una clasificación que el sitio nunca ha tenido; por tanto, este servidor rechaza las tres en lugar de enviarlas.

Cuándo una búsqueda no encuentra nada

La etiqueta que no existe vacía una búsqueda exactument como lo hace una combinación de la que el sitio no tiene nada. Cuándo una búsqueda de varias etiquetas vuelve vacía, este servidor le pregunt al sitio cuáles de los nombres guarda, y la respuesta dice cuáles no

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.

Qué contiene una respuesta

Todas las respuestas llevan el total que el sitio contó para toda la búsqueda, la página que se sirvió y la búsqueda enviada en el idioma del propio sitio. Un post lleva su página de rule34.xxx, su archivo, su thumbnail, sus dimensiones, su puntuación, su clasificación, sus etiquetas, lo que quien lo subió acreditó como fuente, y la fecha de publicación.

En un post hay dos fechas y solo una de ellas es la de publicación: un post subido por primra vez en 2016 y puest etiquetas de nuevo la primavera pasada lleva las dos, y este servidor informa de la primera.

Lo que este servidor no hace

Aveces no sube, vota, comenta ni escribe nada en rule34.xxx.

Errores

Todo fallor lleva uno de seis códigos, y el códig opens el mensaje: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.

rate_limited signi that el sitio esté rechazando a este cliente por ahora, y nunca signifusque la búsqueda no ha encontrado nada. El sitio limita su tasa sin publicar cuál, así que este cliente has asks one data at a time, con un segundo between dos peticios que ninguna configuración puede shortar, y se echa atrás más cuando el sitio lo rejecta.

Usarlo aquí de libería

La cap de lecturas se publica por aseparado, sin el protocolo:

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

Trae el mismo cadencia, la misma caché y la misma taxonomía de erores.

Desarrollo

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

Assuite en vivo lla se conecta con el sitio y solo café en cuando hay credencales:

RULE34_USER_ID=… RULE34_API_KEY=… npm run test:live

Licencia

MIT.


mcp-shell_rule34 (français)

Un serveur MCP pour le rule34.xxx. Cherche les postes du site par tag, à travurs (via) sa propre API, et pour **ches le rouge pour chec'un each par sa page: , son fichier, ses dimensions, son score, la sa mention and ses tag, vec le nombre de posts que l'ensemble de la recherche toto trouve.

Ce serveurur demande des credentials. rule34.xxx vissu une clé d'API par compte, et ses conditions n'autorison la lecture automatisée que par cette API. En obtenir une s'opère en une minuto, êtes descrie in [Configuración] (#configuración-1 ).

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, et tout client au format standard

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

À placer dans votre configuración utilisateur plutôt que dans un fichier de projet : un .mcp.json à la raíz d'un dépôt part avec le dépôt, et la clé parte avec lui.

Configuration

Variable

Ce que c'est

Défaut

RULE34_USER_ID

L'identifieur numérique du compte. Obligatoire.

—

RULE34_API_KEY

La clé d'API. Obligatoire, et personnelle.

—

RULE34_MIN_INTERVAL_MS

Millisecondes entre deux requêtes.

1000, jamais moins

RULE34_TIMEOUT_MS

Durée maximale d'une requête.

20000

RULE34_MAX_RETRIES

Tentatives après la première, sur panne passagère.

3

RULE34_CACHE_TTL_MS

Durée de vie d'une réponse en mémoire.

300000

RULE34_CACHE_MAX_ENTRIES

Nombre de réponses gardées en mémoire.

300

RULE34_USER_AGENT

Remplace l'agent que ce client envoie.

mcp-rule34/<version> (+…)

RULE34_LOG_LEVEL

silent, error, info ou debug, sur stderr.

error

Où trouver les identifiants. Connectez-vous, ouvrez le lien suivant : les reoptions du compte, et cherchez le ligne API Access Credentials. Cette ligne affiche &api_key=…&user_id=… : ces deux values vont dans la configuration ci-dessus. Si la clé est vide, pilez la case Generate New Key? puis enregistrez.

Le site délivre une clé par personne et requérir les applications qui servent le contenu ne diffuser no suffixe advertising ni ne le mettre derrière un paywall. Ce serveur n'embarque aucune clé, et chacun apporte la sienne.Agence.

Un serveur démarré sans credentials démarre quand même, publie son option, et répond à tous les en donnant le nom des deux remarquables à régler. Il n'émet aucune requête qu'il sait le site refuser.

Les outils

Outil

Ce qu'il fait

Paramètres principaux

search_posts

Trouve les posts port le tag ou plusieurs.

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

get_post

Lit un post complèvement, avec le type de chacun de ses tags.

id, url

La recherche nomme les posts, la fiche les lit complete

Un post publier sur rule34.xxx porte en moyenne deux cents tags, et certains en portent neuf cents. Une page de vingt résultats avec tous les tags écrits dedans remplirait quatre cinquièmes de réponse avec des lives que personne ne lit, donc une ligne de recherche affiche les 12 premiers et en compte le nombre.

get_post lit un post par sonid, ou par un lien vers sa page, et renvoie chaque tag avec sa faction (personnage, copyright, artiste, général, méta) et combien de posts se partagent le même, ainsi que l'auteur, sur la numéro nombre de comments and de la date de publication. Un lien est lu au lieu d'être suivi : il commande sa succursale à la valeur id qu'il trouve dans.

Lire un post coûte deux requêtes, car aucun format API fournit ne comporte pas: la date de création est de l'un, et l'auteur, du nombre de du commentaire et le types de étiquettes de l'autre.

Tags sont des tokens uniques

rule34.xxx rient une tag sous forme de single token, à il joint en lower ce qu'une personne dit en mots. asuka langley so hryu et asuka_langley_sohryu son les *****s même tag, et ce serveur d'écrit le seconde étape primaire. La ponctuation dans un nom appartiend à la rien: Cette fiche est ranma_1/2, universellement de la barre.

Listes, listes

{
  "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
}

Le filter activated in arguments sur son, mais pas dans tags, afin que la réponse indique pour la quote et le trim effect actually.

Demander des images, des animations ou des URL video

media_type est support image, animated, video ou any. Le site garde différence dans ses étiquettes.

La note s'effectue par absence : le site étiquete la couleur noire et blanc, et non le color. Demandez une couleur "exclue": ["monochrome", "greyscale","grayscale".

Niveaux de classification

Le site nécessite deux classifications : questionable et explicit. Quand on request@sites safe,general ou sensitive, reçoit de celement aucun posts et pas d'ration, ce qui se lit comme une absence de contenu plutôt d'une connue expiration, donc le serveur rejet de ces classifications.

Quand un appel "trouve rien

A tun tag quel n'existe pas est vide un separator de manière exactement identique à une piste composée que le site ne comporte pas. Quand une recherche de plusieurs tags retourme vide, le serveur demande du ou des sites qui tiennent les noms, et il répond à plus tard: ...

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.

Ce que la réponse présente

Chaque quotidiententement a le site compte pour toute la recherche, la page générée, est la recherche suite aux recherches dans le langage du site. Un post présente la page rule34.xxx, son fichier, sa miniature, sa d "dimension", son score, sa classification, ses tags, et tout ce que l'username a indiqué comme source, ainsi que la date de publication.

La passe deux dates sur un post et elle n'est qu'une : une partition publiée pour le meilleure premier en 2016 est annoncée avec son tag la manière « dents dernières. »...

Pes de foncties de ce serveur

Impossible de modifier, voter, commenter ou envoyer quoi que ce soit à rule34.xxx.

El'erre

Cerrra un fail est désigniérmàn par six codes, le code ouvré le message, not_found, invalid_input, rate_limited, etc.

Bparing clé param.

Utilisation comme bibliothéque

La couche de lecture est publiée à part, sans protocole, sous le lien :

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

Elle embarque, en tampon et la même accion.

Developpement

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

Suite de live voit le site et GXPL.

RULE34_USER_ID=… RULE34_API_KEY=… npm run test:live

Licence

MIT.

get_post lee un post por su identificador, o por un enlace a su página, y devuelve cada etiqueta con su tipo, personaje, copyright, artista, general o metadato, y el número de posts que la comparten, con el usuario que lo subió, el número de comentarios y la fecha de publicación. Un enlace se lee, no se sigue: este servidor construye su propia solicitud a partir del identificador que encuentra en él.

Leer una ficha cuesta dos solicitudes, porque ninguno de los dos formatos publicados por el API lo incluye todo: la fecha de publicación viene de uno, y el nombre del usuario que lo subió, el número de comentarios y los tipos de etiquetas vienen del otro.

Una etiqueta es una sola palabra

rule34.xxx almacena una etiqueta como una sola palabra, uniendo con guiones bajos lo que una persona dice en varias. asuka langley sohryu y asuka_langley_sohryu son la misma etiqueta, y este servidor escribe la segunda a partir de la primera. La puntuación de un nombre le pertenece: la etiqueta de la serie es ranma_1/2, barra incluida.

Tres listas, tres preguntas

{
  "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à
}

Los filtros viven en sus propios argumentos en lugar de en las etiquetas, lo que permite que una respuesta declare la clasificación y el orden que realmente ha aplicado.

Pedir imágenes, animaciones o vídeo

media_type acepta image, animated, video o any. rule34.xxx mantiene esa distinción en sus propias etiquetas, así que es el sitio el que filtra y el total que devuelve refleja fielmente lo solicitado. La clasificación vale, por tanto, lo que vale el trabajo de sus colaboradores.

El color se expresa por una ausencia: el sitio etiqueta el blanco y negro, y no etiqueta nada para indicar que un post es a color. Solicite el color con "exclude": ["monochrome", "greyscale", "grayscale"].

Las clasificaciones

El sitio mantiene dos clasificaciones: questionable y explicit. Pedir safe, general o sensitive a rule34.xxx devuelve cero posts y ningún error, lo cual se lee como una ausencia más que como una clasificación que el sitio nunca ha tenido, así que este servidor rechaza esas tres en lugar de transmitirlas.

Cuando una búsqueda no encuentra nada

Una etiqueta que no existe vacía una búsqueda exactamente igual que una combinación de la que el sitio no tiene nada. Cuando una búsqueda de varias etiquetas devuelve vacío, este servidor pregunta al sitio cuáles de esos nombres posee, y la respuesta indica el que no conoce.

Lo que expresa una respuesta

Cada respuesta lleva el total contado por el sitio para la búsqueda completa, la página servida y la petición tal como fue enviada en el lenguaje del sitio. Un post incluye su página rule34.xxx, su archivo, su miniatura, sus dimensiones, su importe de puntuación, su clasificación, sus etiquetas, la fuente acreditada por el usuario que lo subió, una vez la acreditó, y su fecha de publicación.

Un post lleva dos fechas y solo una es la de publicación: una imagen subida en 2016 y reetiquetada la primavera pasada lleva las dos, y este servidor devuelve la primera.

Lo que este servidor no hace

No sube nada, no vota, no comenta y no escribe nada en rule34.xxx.

Las pruebas

Todo fallo lleva uno de seis códigos, puesta en contacto:... Y el código abre el mensaje: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.

rate_limited significa que un sitio rechaza a este cliente por ahora, y jamás que la búsqueda no ha encontrado nada. rule34.xxx limita su regimen sin publicarlo, así que este cliente hace una pregunta cada vez, con un segundo entre dos peticiones que ninguna configuración puede acortar, y y cuando el sitio lo rechaza.

Usarlo como biblioteca

La capa de lectura se publica sola, sin el protocolo:

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

Lleva el mismo ritmo, el mismo caché y el mismo type de error as.

Desarrollo

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

Un suite en pruebas alcanza el sitio y solo se ejecuta con de acceso:

RULE34_USER_ID=… RULE34_API_KEY=… npm run test:live

Licencia

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