mcp-rule34
mcp-rule34
Сервер MCP для rule34.xxx. Ищет посты сайта по тегу через его собственный API и возвращает для каждого поста его страницу, файл, размеры, оценку, рейтинг и полный список тегов, а также количество постов, соответствующих всему поиску.
Этому серверу нужны учётные данные. rule34.xxx выдаёт ключ API на каждый аккаунт, и его условия разрешают автоматическое чтение только через API. Получение ключа занимает минуту и описано в разделе Конфигурация.
(Version française plus bas / Французская версия ниже)
Quickstart
Claude Code
claude mcp add rule34 --env RULE34_USER_ID=your-id --env RULE34_API_KEY=your-key -- npx -y mcp-rule34Claude Desktop, Cursor и любой клиент, использующий стандартный формат конфигурации
{
"mcpServers": {
"rule34": {
"command": "npx",
"args": ["-y", "mcp-rule34"],
"env": {
"RULE34_USER_ID": "your-id",
"RULE34_API_KEY": "your-key"
}
}
}
}Поместите это в вашу пользовательскую конфигурацию, а не в файл проекта: .mcp.json в корне репозитория путешествует вместе с репозиторием, и ключ путешествует вместе с ним.
Related MCP server: Civitai MCP Server
Configuration
Variable | Что это такое | По умолчанию |
| Ваш числовой идентификатор аккаунта. Обязательно. | — |
| Ваш ключ API. Обязателен и личный. | — |
| Миллисекунды между двумя запросами. |
|
| Сколько времени может занять один запрос. |
|
| Попытки после первой, при временных сбоях. |
|
| Как долго ответ остаётся в памяти. |
|
| Сколько ответов остаётся в памяти. |
|
| Переопределяет агент, который отправляет этот клиент. |
|
|
|
|
Откуда берутся учётные данные. Войдите, откройте Параметры аккаунта и найдите строку API Access Credentials. Она показывает &api_key=…&user_id=…; эти два значения и есть то, что идёт в конфигурацию выше. Если ключ пуст, отметьте Generate New Key? и сохраните.
Сайт выдаёт один ключ на человека и просит, чтобы приложения, обслуживающие его контент, не показывали рекламу и не ставили его за платный доступ. Этот сервер не поставляет собственный ключ, и каждый пользователь приносит свой.
Сервер, запущенный без учётных данных, всё равно запускается, публикует свой инструмент и отвечает на каждый вызов, называя две переменные, которые нужно установить. Он никогда не отправляет запрос, который, как он знает, сайт отклонит.
Инструменты
Инструмент | Что делает | Ключевые параметры |
| Находит посты с тегом или несколькими сразу. |
|
| Читает один пост целиком, с типом для каждого тега. |
|
| Находит, как сайт пишет тег, и сколько постов его несут. |
|
Как пишется тег
find_tags спрашивает rule34.xxx, какие имена начинаются с фрагмента текста, и сколько постов несёт каждое. Он сопоставляет с начала имени, поэтому kimagure находит kimagure_orange_road, а слово, находящееся в середине имени, не находит ничего. Сайт предлагает не более десяти имён, и ответ сообщает об этом, поскольку десять назад означает, что список был обрезан, а не исчерпан.
Это также то, на что опирается поиск, не нашедший ничего: когда требуемый тег не существует, ответ называет его и предлагает имена, которые сайт действительно содержит и которые начинаются с него.
Поиск называет посты, затем пост читается целиком
Пост на rule34.xxx несёт в среднем около двухсот тегов, а некоторые несут девятьсот. Страница из двадцати результатов с полным перечислением тегов потратила бы четыре пятых ответа на строки тегов, которые никто не читает, поэтому строка поиска показывает первые двенадцать и указывает, сколько всего тегов несёт пост.
get_post читает один пост по его id или по ссылке на его страницу и возвращает каждый тег с его типом: персонаж, копирайт, художник, общий или метаданные, и сколько постов его разделяют, вместе с загрузившим, количеством комментариев и датой, когда сайт его принял. Ссылка читается, а не переходит: этот сервер строит собственный запрос из id, который он в ней находит.
Чтение одного поста стоит двух запросов, потому что ни один из форматов, публикуемых API, не содержит всего: дата, когда сайт принял пост, берётся из одного, а имя загрузившего, количество комментариев и типы тегов — из другого.
Теги — это одиночные токены
rule34.xxx хранит тег как один токен, соединяя подчёркиваниями то, что человек говорит словами. asuka langley sohryu и asuka_langley_sohryu — это один и тот же тег, и этот сервер пишет второй из первого. Пунктуация внутри имени принадлежит ему: тег серии — ranma_1/2, включая слэш.
Три списка, три вопроса
{
"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
}Фильтры живут в собственных аргументах, а не внутри тегов, поэтому ответ может указать рейтинг и сортировку, которые фактически использовались.
Запрос изображений, анимаций или видео
media_type принимает image, animated, video или any. rule34.xxx несёт различие в собственных тегах, поэтому сайт выполняет фильтрацию, и возвращаемый итог учитывает то, что было запрошено. Таким образом, классификация настолько же хороша, насколько хороша разметка сайта.
Цвет указывается по отсутствию: сайт помечает то, что чёрно-белое, и не помечает ничего, чтобы сказать, что пост цветной. Запросите цвет с помощью "exclude": ["monochrome", "greyscale", "grayscale"].
Рейтинги
Сайт содержит два рейтинга: questionable и explicit. Запрос к rule34.xxx за safe, general или sensitive возвращает ноль постов и без ошибки, что читается как отсутствие, а не как рейтинг, которого у сайта никогда не было, поэтому этот сервер отказывает этим трём вместо того, чтобы передавать их.
Когда поиск ничего не находит
Тег, который не существует, опустошает поиск точно так же, как комбинация, для которой у сайта ничего нет. Когда поиск по нескольким тегам возвращается пустым, этот сервер спрашивает сайт, какие из имён он содержит, и ответ говорит, какого именно нет:
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.Что содержит ответ
Каждый ответ несёт итог, который сайт подсчитал для всего поиска, страницу, которая была обслужена, и поиск, как он был отправлен на собственном языке сайта. Пост несёт свою страницу rule34.xxx, файл, миниатюру, размеры, оценку, рейтинг, теги, всё, что загрузивший указал как источник, и дату, когда rule34.xxx принял его.
Пост несёт две даты, и ни одна из них не является датой создания его предмета. Первая — день, когда сайт принял пост, вторая — день последнего изменения поста, которое сдвигает перетегирование. rule34.xxx импортировал большую часть своего старого каталога массово, поэтому тысячи постов разделяют один день в ноябре 2010 года: вопрос о том, что было раньше, решается импортом, а не работой.
Чего этот сервер не делает
Он никогда не загружает, не голосует, не комментирует и не пишет ничего на rule34.xxx.
Ошибки
Каждый сбой несёт один из шести кодов, и код открывает сообщение: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.
rate_limited означает, что сайт временно отказывает этому клиенту, и это никогда не означает, что поиск ничего не нашёл. rule34.xxx ограничивает свою частоту, не публикуя, какова она, поэтому этот клиент задаёт один вопрос за раз, с секундой между двумя запросами, которую никакая конфигурация не может сократить, и он отступает дальше, когда сайт отталкивает.
Использование в качестве библиотеки
Слой чтения публикуется отдельно, без протокола:
import { Rule34Client } from "mcp-rule34/client";Он несёт тот же темп, тот же кэш и ту же таксономию ошибок.
Разработка
npm install
npm test # unit tests, no network
npm run typecheck
npm run check # biome and prettier
npm run buildЖивой набор тестов достигает сайта и запускается только при наличии учётных данных:
RULE34_USER_ID=… RULE34_API_KEY=… npm run test:liveЛицензия
MIT.
mcp-rule34 (français)
Un serveur MCP pour rule34.xxx. Cherche les posts du site par tag, à travers sa propre API, et rend pour chacun sa page, son fichier, ses dimensions, son score, sa classification et ses tags, avec le nombre de posts que la recherche entière trouve.
Ce serveur demande des identifiants. rule34.xxx délivre une clé d'API par compte, et ses conditions n'autorisent la lecture automatisée que par cette API. En obtenir une prend une minute, voir Configuration.
Démarrage
Claude Code
claude mcp add rule34 --env RULE34_USER_ID=votre-id --env RULE34_API_KEY=votre-clé -- npx -y mcp-rule34Claude 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 configuration utilisateur plutôt que dans un fichier de
projet : un .mcp.json à la racine d'un dépôt part avec le dépôt, et la clé
part avec lui.
Configuration
Variable | Ce que c'est | Défaut |
| L'identifiant numérique du compte. Obligatoire. | — |
| La clé d'API. Obligatoire, et personnelle. | — |
| Millisecondes entre deux requêtes. |
|
| Durée maximale d'une requête. |
|
| Tentatives après la première, sur panne passagère. |
|
| Durée de vie d'une réponse en mémoire. |
|
| Nombre de réponses gardées en mémoire. |
|
| Remplace l'agent que ce client envoie. |
|
|
|
|
Où trouver les identifiants. Connectez-vous, ouvrez
les options du compte, et
cherchez la ligne API Access Credentials. Elle affiche &api_key=…&user_id=… :
ces deux valeurs vont dans la configuration ci-dessus. Si la clé est vide, cochez
Generate New Key? puis enregistrez.
Le site délivre une clé par personne et demande qu'une application servant son contenu n'affiche aucune publicité et ne le mette derrière aucun péage. Ce serveur n'embarque aucune clé, et chacun apporte la sienne.
Un serveur démarré sans identifiants démarre quand même, publie son outil, et répond à chaque appel en nommant les deux variables à régler. Il n'émet jamais une requête dont il sait que le site la refusera.
Les outils
Инструмент | Что он делает | Основные параметры |
| Находит посты с одним тегом или несколькими. |
|
| Читает пост целиком, с типом каждого из его тегов. |
|
| Находит, как сайт пишет тег, и сколько постов его несут. |
|
Как пишется тег
find_tags спрашивает у rule34.xxx, какие имена начинаются с текста, и сколько постов несёт каждое. Соответствие идёт от начала имени, поэтому kimagure находит kimagure_orange_road, тогда как слово в середине имени не находит ничего. Сайт предлагает не более десяти имён, и ответ это говорит, поскольку десять в ответе означают обрезанный список, а не исчерпанный.
Это также запасной вариант поиска, который ничего не нашёл: когда требуемый тег не существует, ответ называет его и предлагает имена, которые есть на сайте и начинаются так же.
Поиск называет посты, карточка читает их целиком
Пост на rule34.xxx несёт в медиане около двухсот тегов, а некоторые несут девятьсот. Страница из двадцати результатов со всеми записанными тегами потратила бы четыре пятых своего ответа на строки, которые никто не читает, поэтому строка поиска показывает первые двенадцать и говорит, сколько всего тегов несёт пост.
get_post читает пост по его идентификатору или по ссылке на его страницу и возвращает каждый тег с его типом — персонаж, копирайт, художник, общий или метаданные — и количество постов, которые его разделяют, вместе с загрузившим, количеством комментариев и датой, когда сайт его взял. Ссылка читается, а не переходит: этот сервер строит собственный запрос из идентификатора, который он в ней находит.
Чтение карточки стоит двух запросов, потому что ни один из двух форматов, публикуемых API, не несёт всего: дата, когда сайт взял пост, приходит из одного, а имя загрузившего, количество комментариев и типы тегов — из другого.
Тег — это одно слово
rule34.xxx помещает тег в одно слово, соединяя подчёркиваниями то, что человек говорит несколькими словами. asuka langley sohryu и asuka_langley_sohryu — это один и тот же тег, и этот сервер пишет второй из первого. Пунктуация имени принадлежит ему: тег серии — ranma_1/2, включая косую черту.
Три списка, три вопроса
{
"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à
}Фильтры живут в собственных аргументах, а не в тегах, что позволяет ответу называть классификацию и сортировку, которые он действительно применил.
Запрашивать изображения, анимации или видео
media_type принимает image, animated, video или any. rule34.xxx несёт различие в собственных тегах, поэтому фильтрует сайт, и итог, который он возвращает, хорошо отражает то, что было запрошено. Ранжирование стоит столько, сколько стоит работа его участников.
Цвет выражается отсутствием: сайт помечает чёрно-белое и не помечает ничего, чтобы сказать, что пост цветной. Запрашивайте цвет через "exclude": ["monochrome", "greyscale", "grayscale"].
Классификации
Сайт ведёт две классификации: questionable и explicit. Запрос safe, general или sensitive к rule34.xxx возвращает ноль постов и никакой ошибки, что читается как отсутствие, а не как классификация, которой у сайта никогда не было, поэтому этот сервер отказывает этим трём вместо того, чтобы их передавать.
Когда поиск ничего не находит
Несуществующий тег опустошает поиск точно так же, как комбинация, которой у сайта нет. Когда поиск по нескольким тегам возвращается пустым, этот сервер спрашивает у сайта, какие из этих имён он держит, и ответ называет то, которое он не знает.
Что называет ответ
Каждый ответ несёт итог, посчитанный сайтом для всего поиска, обслуженную страницу и запрос, как он был отправлен на языке сайта. Пост несёт свою страницу rule34.xxx, свой файл, свою миниатюру, свои размеры, свой счёт, свою классификацию, свои теги, источник, указанный загрузившим, когда он указал его, и дату, когда rule34.xxx его взял.
Пост несёт две даты, и ни одна не является датой создания его сюжета. Первая — день, когда сайт взял пост, вторая — день, когда он изменился в последний раз, который сдвигает перетегирование. rule34.xxx массово импортировал большую часть своего старого фонда, поэтому тысячи постов несут один и тот же день ноября 2010 года: вопрос о том, что идёт первым, получает ответ от импорта, а никогда от произведения.
Чего этот сервер не делает
Он ничего не загружает, не голосует, не комментирует и ничего не пишет на rule34.xxx.
Ошибки
Любой сбой несёт один из шести кодов, и код открывает сообщение: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.
rate_limited означает, что сайт отказывает этому клиенту на данный момент, и никогда — что поиск ничего не нашёл. rule34.xxx ограничивает свой трафик, не публикуя какой именно, поэтому этот клиент задаёт один вопрос за раз, с секундой между двумя запросами, которую никакая конфигурация не может сократить, и он отступает сильнее, когда сайт его отталкивает.
Использование как библиотеки
Слой чтения публикуется отдельно, без протокола:
import { Rule34Client } from "mcp-rule34/client";Он несёт тот же ритм, тот же кэш и ту же таксономию ошибок.
Разработка
npm install
npm test # tests unitaires, sans réseau
npm run typecheck
npm run check # biome et prettier
npm run buildЖивой набор тестов достигает сайта и работает только с идентификаторами:
RULE34_USER_ID=… RULE34_API_KEY=… npm run test:liveЛицензия
MIT.
Available Tools
3 toolsfind_tagsFind how a tag is spelledARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The start of a tag name, such as 'kimagure' or 'prince of tennis'. Spaces are joined with underscores. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| notes | Yes | |
| query | Yes | The text as rule34.xxx would spell it. |
| source | Yes |
TDQS
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.
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.
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.
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.
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.
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 postARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The post's numeric id, as a search returns it. | |
| url | No | A 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
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| md5 | Yes | |
| tags | Yes | |
| notes | Yes | |
| owner | Yes | The account that uploaded the post. |
| score | Yes | The site's own score, updated once a day. |
| width | Yes | |
| height | Yes | |
| rating | Yes | |
| source | Yes | |
| status | Yes | |
| file_url | Yes | |
| post_url | Yes | |
| has_notes | Yes | |
| parent_id | Yes | |
| changed_at | Yes | When the post last changed, ISO 8601. |
| created_at | Yes | When 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_url | Yes | |
| preview_url | Yes | |
| source_site | Yes | |
| comment_count | Yes |
TDQS
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.
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.
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.
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.
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.
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 tagARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | '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 |
| tags | Yes | Tags a post must all carry, such as ['asuka langley sohryu', 'black hair']. | |
| limit | No | ||
| any_of | No | Tags a post must carry at least one of. | |
| rating | No | The two ratings rule34.xxx holds. Leave unset to search both. | |
| exclude | No | Tags a post must not carry, such as ['monochrome'] to leave out black and white. | |
| media_type | No | '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
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| tags | Yes | The required tags, as rule34.xxx spells them. |
| notes | Yes | |
| posts | Yes | |
| query | Yes | The search as it was sent, in the site's own language. |
| total | Yes | Posts the whole search matches, as counted by the site. |
| any_of | Yes | The alternatives, as rule34.xxx spells them. |
| source | Yes | |
| exclude | Yes | The excluded tags, as rule34.xxx spells them. |
| has_more | Yes | |
| next_page | Yes |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v2.0.1- Changed
get_post12 fields changed- removed
Output schema / properties / changed_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / changed_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / owner / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / owner / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / preview_url / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / preview_url / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / sample_url / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / sample_url / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / source / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / source / typeAdded value: +[ + "string", + "null" +]
- Changed
search_posts8 fields changed- removed
Output schema / properties / posts / items / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / posts / items / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / posts / items / properties / preview_url / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / posts / items / properties / preview_url / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / posts / items / properties / sample_url / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / posts / items / properties / sample_url / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / posts / items / properties / source / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / posts / items / properties / source / typeAdded value: +[ + "string", + "null" +]
3 tool updates
v1.1.0- First observed
find_tags - First observed
get_post - First observed
search_posts
TDQS
Scored across 3 tools
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.
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.
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.
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
Related MCP Connectors
Search adult porn video (NSFW, 18+): nude clips, creators, hashtags. Read-only, no API key.
Search adult porn video (NSFW, 18+): nude clips, creators, hashtags. Read-only, no API key.
Search adult porn video (NSFW, 18+): nude clips, creators, hashtags. Read-only, no API key.
- LerpOAuthgallery.lerp
Search website motion, specs and recreation packs. Account required; OAuth or bearer API key.
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceEnables 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-
- AlicenseNot gradedqualityDmaintenanceEnables 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
- AlicenseAqualityDmaintenanceSearches Danbooru for anime/game characters and their associated tags, providing tools to retrieve character profiles, co-occurring tags, wiki descriptions, and tag implications.512MIT
- AlicenseNot gradedqualityDmaintenanceEnables semantic search of Danbooru tags using natural language queries to generate precise prompts for anime-style image generation.7MIT