rule34.xxx용 MCP 서버입니다. 자체 API를 통해 태그로 사이트의 게시물을 검색하고, 각 게시물의 페이지, 파일, 크기, 점수, 등급, 전체 태그 목록과 함께 전체 검색 결과 수를 반환합니다.
이 서버는 자격 증명이 필요합니다. rule34.xxx는 계정별로 API 키를 발급하며, 이용 약관상 자동화된 읽기는 API를 통해서만 허용됩니다. 키를 얻는 데는 1분이 걸리며 Configuration에서 설명합니다.
(Version française plus bas / 프랑스어 버전은 아래)
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
변수 | 설명 | 기본값 |
| 계정의 숫자 ID. 필수. | — |
| API 키. 필수이며 개인 정보입니다. | — |
| 두 요청 사이의 밀리초. |
|
| 한 요청이 걸릴 수 있는 시간. |
|
| 일시적 실패에 대한 첫 시도 이후의 재시도 횟수. |
|
| 답변이 메모리에 유지되는 시간. |
|
| 메모리에 유지되는 답변 수. |
|
| 이 클라이언트가 보내는 에이전트를 재정의합니다. |
|
|
|
|
자격 증명을 얻는 방법. 로그인한 후 Account options를 열고 API Access Credentials라는 행을 찾으세요. &api_key=…&user_id=…가 표시됩니다. 이 두 값이 위 구성에 들어가는 값입니다. 키가 비어 있으면 *Generate New Key?*를 체크하고 저장하세요.
사이트는 사람당 하나의 키를 발급하며, 해당 콘텐츠를 제공하는 애플리케이션이 광고를 표시하지 않고 페이월 뒤에 두지 않도록 요청합니다. 이 서버는 자체 키를 포함하지 않으며, 각 사용자가 자신의 키를 가져옵니다.
자격 증명 없이 시작된 서버는 여전히 시작되고, 도구를 게시하며, 모든 호출에 설정할 두 변수를 명명하여 응답합니다. 사이트가 거부할 것을 알면서 요청을 보내지 않습니다.
도구 | 기능 | 주요 매개변수 |
| 태그 하나 또는 여러 개를 가진 게시물을 찾습니다. |
|
| 게시물 하나를 전체 읽고, 각 태그에 종류를 붙입니다. |
|
| 사이트가 태그를 어떻게 표기하는지, 그리고 그 태그를 가진 게시물 수를 찾습니다. |
|
find_tags는 rule34.xxx에 텍스트 조각으로 시작하는 이름과 각각이 가진 게시물 수를 묻습니다. 이름의 시작 부분에서 일치하므로 kimagure는 kimagure_orange_road를 찾지만, 이름 중간에 있는 단어는 아무것도 찾지 못합니다. 사이트는 최대 10개의 이름을 제공하며, 답변은 그 사실을 명시합니다. 10개가 반환되면 목록이 잘렸다는 뜻이지 모두 소진된 것이 아니기 때문입니다.
이것은 검색 결과가 없을 때의 대체 수단이기도 합니다. 필수 태그가 존재하지 않으면 답변은 그 태그를 명명하고, 사이트가 보유한 이름 중 그 태그로 시작하는 이름을 제안합니다.
rule34.xxx의 게시물은 중앙값 약 200개의 태그를 가지며, 일부는 900개를 가집니다. 모든 태그를 나열한 20개 결과 페이지는 아무도 읽지 않는 태그 문자열에 답변의 4/5를 소비하게 되므로, 검색 행은 처음 12개만 표시하고 게시물이 총 몇 개의 태그를 가지는지 명시합니다.
get_post는 ID 또는 페이지 링크로 게시물 하나를 읽고, 모든 태그를 종류(character, copyright, artist, general, metadata)와 함께 반환하며, 해당 태그를 공유하는 게시물 수, 업로더, 댓글 수, 사이트가 받은 날짜도 반환합니다. 링크는 따라가지 않고 읽습니다. 이 서버는 링크에서 찾은 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를 요청하면 0개의 게시물과 오류 없이 반환되며, 이는 사이트가 가진 적 없는 등급이 아니라 부재로 읽힙니다. 따라서 이 서버는 세 가지를 전달하는 대신 거부합니다.
존재하지 않는 태그는 사이트가 보유하지 않은 조합과 똑같이 검색을 비웁니다. 여러 태그 검색이 비어 돌아오면 이 서버는 사이트에 어떤 이름을 보유하고 있는지 묻고, 답변은 어떤 이름이 없는지 말합니다:
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년 11월의 하루를 공유합니다. 무엇이 먼저 왔는지에 대한 질문은 작품이 아니라 가져오기로 답합니다.
rule34.xxx에 업로드, 투표, 댓글 작성 또는 어떤 것도 쓰지 않습니다.
모든 실패는 여섯 가지 코드 중 하나를 가지며, 코드가 메시지를 엽니다: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.
rate_limited는 사이트가 현재 이 클라이언트를 거부하고 있음을 의미하며, 검색 결과가 없다는 뜻이 아닙니다. rule34.xxx는 요율을 공개하지 않고 제한하므로 이 클라이언트는 한 번에 하나의 질문을 하고, 두 요청 사이에 구성으로 줄일 수 없는 1초를 두며, 사이트가 밀어낼 때 더 물러납니다.
읽기 계층은 프로토콜 없이 자체적으로 게시됩니다:
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:liveMIT.
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.
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.
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.
도구 | 기능 | 주요 매개변수 |
| 태그 하나 또는 여러 개를 가진 게시물을 찾습니다. |
|
| 게시물 전체와 각 태그의 유형을 읽습니다. |
|
| 사이트가 태그를 어떻게 표기하는지, 그리고 그 태그를 가진 게시물이 몇 개인지 찾습니다. |
|
find_tags는 rule34.xxx에 어떤 이름이 특정 텍스트로 시작하는지, 그리고 각각이 몇 개의 게시물을 가졌는지 묻습니다. 일치는 이름의 시작 부분에서 이루어지므로, kimagure는 kimagure_orange_road를 찾지만 이름 중간에 있는 단어는 아무것도 찾지 못합니다. 사이트는 최대 열 개의 이름을 제시하며, 응답이 이를 알려줍니다. 열 개가 반환되면 목록이 완전히 소진된 것이 아니라 잘렸다는 뜻이기 때문입니다.
이것은 아무것도 찾지 못한 검색의 대체 수단이기도 합니다. 요청한 태그가 존재하지 않으면 응답이 그 태그를 명시하고, 사이트가 보유한 이름 중 그와 같은 시작을 가진 이름들을 제안합니다.
rule34.xxx의 게시물은 중앙값 기준 약 이백 개의 태그를 가지며, 어떤 것은 구백 개를 가집니다. 모든 태그를 적은 스무 개 결과 페이지는 응답의 5분의 4를 아무도 읽지 않는 문자열에 쓸 것이므로, 검색 줄은 처음 열두 개를 보여주고 게시물이 총 몇 개의 태그를 가졌는지 말합니다.
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 두 가지 분류를 유지합니다. rule34.xxx에 safe, general 또는 sensitive를 요청하면 게시물이 0개이고 오류도 없습니다. 이는 사이트가 가진 적 없는 분류라기보다 부재로 읽히므로, 이 서버는 이 세 가지를 전달하는 대신 거부합니다.
존재하지 않는 태그는 사이트에 아무것도 없는 조합과 똑같이 검색을 비웁니다. 여러 태그 검색이 비어 돌아오면, 이 서버는 사이트에 그 이름 중 어떤 것을 보유하고 있는지 묻고, 응답은 사이트가 모르는 이름을 말합니다.
각 응답은 사이트가 전체 검색에 대해 센 총계, 제공된 페이지, 그리고 사이트의 언어로 전송된 요청을 담고 있습니다. 게시물은 rule34.xxx 페이지, 파일, 썸네일, 크기, 점수, 분류, 태그, 업로더가 출처를 표시했을 때 그 출처, 그리고 rule34.xxx가 게시물을 가져간 날짜를 담고 있습니다.
게시물은 두 개의 날짜를 가지며, 어느 것도 그 주제가 만들어진 날짜가 아닙니다. 첫 번째는 사이트가 게시물을 가져간 날이고, 두 번째는 게시물이 마지막으로 변경된 날이며, 재태깅이 이를 옮깁니다. rule34.xxx는 오래된 자료의 상당 부분을 대량으로 가져왔으므로, 수천 개의 게시물이 2010년 11월의 같은 날짜를 가집니다. 무엇이 먼저인지에 대한 질문은 작품이 아니라 가져오기에 의해 답해집니다.
이 서버는 아무것도 업로드하지 않고, 투표하지 않으며, 댓글을 달지 않고, rule34.xxx에 아무것도 쓰지 않습니다.
모든 오류는 여섯 개의 코드 중 하나를 가지며, 코드가 메시지를 엽니다: not_found, invalid_input, rate_limited, parse_failure, network_error, timeout.
rate_limited는 사이트가 현재 이 클라이언트를 거부한다는 뜻이며, 검색 결과가 없다는 뜻이 결코 아닙니다. rule34.xxx는 한도를 공개하지 않고 요청 속도를 제한하므로, 이 클라이언트는 한 번에 하나의 질문을 하고, 어떤 구성으로도 줄일 수 없는 1초 간격을 두며, 사이트가 밀어낼 때 더 멀리 물러납니다.
읽기 계층은 프로토콜 없이 단독으로 공개됩니다:
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:liveMIT.
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. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| notes | Yes | |
| query | Yes | The text as rule34.xxx would spell it. |
| source | Yes |
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.
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. |
| 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 |
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 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 |
| 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 |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.1get_post12 fields changedOutput schema / properties / changed_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / changed_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / created_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / created_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / owner / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / owner / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / preview_url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / preview_url / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / sample_url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / sample_url / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / source / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / source / typeAdded value: +[
+ "string",
+ "null"
+]search_posts8 fields changedOutput schema / properties / posts / items / properties / created_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / posts / items / properties / created_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / posts / items / properties / preview_url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / posts / items / properties / preview_url / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / posts / items / properties / sample_url / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / posts / items / properties / sample_url / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / posts / items / properties / source / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / posts / items / properties / source / typeAdded value: +[
+ "string",
+ "null"
+]v1.1.0find_tagsget_postsearch_postsScored 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.
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.
Search website motion, specs and recreation packs. Account required; OAuth or bearer API key.
