mcp-rule34

Read one post

get_post

Read-onlyIdempotent

Retrieve full details for a Rule34 post by ID or page link: categorized tags with counts, media file, dimensions, score, rating, uploader, comments, source, and date.

Instructions

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.

Input Schema

TableJSON Schema

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

TableJSON 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

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv2.0.1Aug 29, 2026

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"
+]
```

First observedv1.1.0Aug 25, 2026

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.

Deploy Server