rule34.xxx 用の MCP サーバーです。サイトの投稿をタグで検索し、各投稿のページ、ファイル、寸法、スコア、レーティング、完全なタグリストを、検索全体が一致する投稿数とともに返します。
このサーバーには認証情報が必要です。 rule34.xxx はアカウントごとに API キーを発行し、その利用規約では API 経由での自動読み取りのみが許可されています。取得には1分もかからず、設定 で説明しています。
(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キー。必須、かつ個人用。 | — |
| 2つのリクエスト間のミリ秒。 |
|
| 1つのリクエストにかかる時間。 |
|
| 一時的な失敗に対する最初の試行後の試行回数。 |
|
| 回答がメモリに保持される時間。 |
|
| メモリに保持される回答数。 |
|
| このクライアントが送信するエージェントを上書きします。 |
|
|
|
|
認証情報の入手先。 サインインし、アカウントオプション を開き、API Access Credentials という行を見つけます。そこには &api_key=…&user_id=… と表示されています。その2つの値が上記の設定に入るものです。キーが空の場合は、Generate New Key? にチェックを入れて保存します。
サイトは一人につき1つのキーを発行し、そのコンテンツを提供するアプリケーションは広告を表示せず、ペイウォールの背後に置かないことを求めています。このサーバーは独自のキーを同梱せず、各ユーザーが自分のキーを持ち込みます。
認証情報なしで起動したサーバーも起動し、ツールを公開し、すべての呼び出しに対して設定すべき2つの変数を指定して応答します。サイトが拒否するとわかっているリクエストは送信しません。
ツール | 機能 | 主なパラメータ |
| タグを持つ投稿、または複数のタグを同時に検索します。 |
|
| 1つの投稿を全体として読み取り、各タグに種類を付けます。 |
|
| サイトがタグをどう綴るか、そしてそのタグを持つ投稿がいくつあるかを検索します。 |
|
find_tags は rule34.xxx に、テキストの一部で始まる名前と、それぞれが持つ投稿数を尋ねます。名前の先頭から一致するため、kimagure は kimagure_orange_road を見つけますが、名前の途中にある単語は何も見つけません。サイトは最大10個の名前を提供し、回答はその旨を伝えます。10個返ってきた場合は、リストが尽きたのではなく切り詰められたことを意味します。
これは、何も見つからなかった検索がフォールバックするものでもあります。必須タグが存在しない場合、回答はそのタグを指名し、サイトが実際に保持している、そのタグで始まる名前を提供します。
rule34.xxx の投稿は中央値で約200個のタグを持ち、中には900個持つものもあります。20件の結果のページで全タグを書き出すと、回答の5分の4を誰も読まないタグ文字列に費やすことになるため、検索行は最初の12個を表示し、投稿が全部でいくつ持っているかを示します。
get_post は、IDまたはページへのリンクで1つの投稿を読み取り、すべてのタグをその種類（キャラクター、著作権、アーティスト、一般、メタデータ）と、そのタグを共有する投稿数とともに返します。さらに、アップロード者、コメント数、サイトが受け付けた日付も返します。リンクはフォローされるのではなく読み取られます。このサーバーは、リンク内で見つけたIDから独自のリクエストを構築します。
1つの投稿を読むには2回のリクエストが必要です。APIが公開する形式のどちらもすべてを保持していないためです。サイトが投稿を受け付けた日付は一方から、アップロード者の名前、コメント数、タグの種類はもう一方から取得します。
rule34.xxx はタグを1つのトークンとして保存し、人が言葉で言うものをアンダースコアで結合します。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 の2つのレーティングがあります。rule34.xxx に safe、general、sensitive を要求すると、0件の投稿とエラーなしが返ります。これはサイトが持っていないレーティングとしてではなく、不在として解釈されるため、このサーバーはこれら3つを渡さずに拒否します。
存在しないタグは、サイトが何も持っていない組み合わせと同じように検索を空にします。複数のタグの検索が空で返ってきた場合、このサーバーはサイトにどの名前を保持しているかを尋ね、回答はどの名前を保持していないかを示します：
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 が受け付けた日付が含まれます。
投稿には2つの日付があり、どちらもその主題が作られた日ではありません。1つ目はサイトが投稿を受け付けた日、2つ目は投稿が最後に変更された日で、タグの付け直しによって変わります。rule34.xxx は古いカタログの多くを一括でインポートしたため、何千もの投稿が2010年11月のある1日を共有しています。何が最初に来たかという質問には、作品ではなくインポートが答えになります。
rule34.xxx にアップロード、投票、コメント、書き込みを一切行いません。
すべての失敗には6つのコードのいずれかが含まれ、コードがメッセージの先頭に付きます：not_found、invalid_input、rate_limited、parse_failure、network_error、timeout。
rate_limited は、サイトが現在このクライアントを拒否していることを意味し、検索が何も見つからなかったことを意味するものではありません。rule34.xxx はレートを公開せずに制限しているため、このクライアントは一度に1つの質問をし、2つのリクエストの間に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.
ツール | 機能 | 主なパラメータ |
| タグを1つまたは複数持つ投稿を検索します。 |
|
| 投稿を完全に読み、各タグのタイプを取得します。 |
|
| サイトがタグをどう表記するか、そして何件の投稿がそのタグを持つかを調べます。 |
|
find_tags は rule34.xxx に、あるテキストで始まる名前と、それぞれが何件の投稿を持つかを尋ねます。照合は名前の先頭から行われるため、kimagure は kimagure_orange_road を見つけますが、名前の途中にある単語は何も見つけません。サイトは最大10個の名前を提示し、応答はそれを示します。10件返ってきた場合は、リストが尽きたのではなく切り詰められたことを意味します。
これはまた、何も見つからなかった検索のフォールバックでもあります。必須タグが存在しない場合、応答はそのタグを指名し、サイトが保持している同じ接頭辞で始まる名前を提案します。
rule34.xxx の投稿は中央値で約200個のタグを持ち、中には900個持つものもあります。全タグを書き出した20件の結果ページは、応答の5分の4を誰も読まない文字列に費やすことになるため、検索行は最初の12個を表示し、投稿が合計で何個のタグを持つかを示します。
get_post は投稿をIDまたはページへのリンクで読み、各タグをそのタイプ（キャラクター、著作権、アーティスト、一般、メタデータ）と、それを共有する投稿数とともに返します。さらに投稿者、コメント数、サイトが投稿を取得した日付も返します。リンクは読み取られ、追跡されません。このサーバーはリンク内のIDから独自のリクエストを構築します。
詳細を読むには2回のリクエストが必要です。APIが公開する2つの形式のどちらもすべてを保持していないためです。サイトが投稿を取得した日付は一方から、投稿者名、コメント数、タグタイプはもう一方から取得します。
rule34.xxx はタグを1つの単語にまとめ、人が複数の単語で言うものをアンダースコアで結合します。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"] を使用します。
サイトは2つの分類を保持しています：questionable と explicit。rule34.xxx に safe、general、sensitive を要求すると、0件の投稿とエラーなしが返ります。これはサイトが持ったことのない分類としてではなく、不在として読まれます。そのため、このサーバーはこれら3つを送信せずに拒否します。
存在しないタグは、サイトが何も持っていない組み合わせとまったく同じように検索を空にします。複数タグの検索が空で返った場合、このサーバーはサイトにこれらの名前のどれを保持しているかを尋ね、応答はサイトが知らないものを示します。
各応答は、サイトが検索全体に対して数えた合計、提供されたページ、およびサイトの言語で送信されたクエリを保持します。投稿は、rule34.xxx のページ、ファイル、サムネイル、寸法、スコア、分類、タグ、投稿者がクレジットした場合のソース、および rule34.xxx が投稿を取得した日付を保持します。
投稿は2つの日付を持ち、どちらもその主題が作られた日付ではありません。1つ目はサイトが投稿を取得した日、2つ目は最後に変更された日で、再タグ付けによって移動します。rule34.xxx は古いコレクションの大部分を一括インポートしたため、何千もの投稿が2010年11月の同じ日付を持っています。何が最初に来るかという質問には、作品ではなくインポートが答えます。
アップロードは行わず、投票もコメントもせず、rule34.xxx に何も書き込みません。
すべての障害は6つのコードのいずれかを保持し、コードがメッセージを開きます：not_found、invalid_input、rate_limited、parse_failure、network_error、timeout。
rate_limited は、サイトが当面このクライアントを拒否していることを意味し、検索が何も見つからなかったことを意味することは決してありません。rule34.xxx はレート制限を公開せずに実施しているため、このクライアントは一度に1つの質問を行い、2つのリクエストの間に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.
