Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

reddit_post

Fetch a public Reddit post by ID and return normalized data; enable metrics for score, upvote ratio, and comment count.

Instructions

Get Reddit post. Returns a normalized public Reddit post. The default 1-credit mode uses RSS. Set include_metrics=true to use the anonymous HTML post page as the sole content request and return public net score, upvote ratio, comment count, award count, and estimated upvote/downvote totals for 3 credits. Reddit fuzzes voting data, so estimates are approximate; share, repost/crosspost, and view counts are not exposed anonymously. Native-source failures can use the internal Redlib fallback; source.type is redlib and public fields/credit weights are preserved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesReddit post id or t3_ id
include_metricsNoInclude public engagement metrics; costs 3 credits instead of 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_metrics
      Added value: +{
+  "description": "Include public engagement metrics; costs 3 credits instead of 1",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.5.0
    • removedInput schema / properties / with_scores
      Removed value: -{
-  "description": "When true, source score, upvote_ratio, and comment_count from old.reddit HTML rather than the default (slower)",
-  "type": "boolean"
-}
  3. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / with_scores
      Added value: +{
+  "description": "When true, source score, upvote_ratio, and comment_count from old.reddit HTML rather than the default (slower)",
+  "type": "boolean"
+}
  4. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the 1-credit vs 3-credit cost model, that voting data is fuzzed and estimates are approximate, that share/repost/view counts are unavailable anonymously, and that a Redlib fallback may be used with source.type reported. It omits auth/rate-limit details but covers the key behavioral traits.

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 core purpose is front-loaded and the sentences are information-dense, each carrying cost/mode/fallback details. It is on the longer side and the Redlib fallback note borders on internal detail, but nothing is egregiously wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description needs to be self-sufficient; it describes the returned shape (normalized post plus optional metric fields) and the fallback behavior. It could say more about what 'normalized' includes or error behavior, but it is largely complete for a 2-parameter read tool.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning to include_metrics beyond the schema: it names the specific returned fields (net score, upvote ratio, comment count, awards, estimated upvote/downvote totals) and the exact credit cost. The id parameter semantics (t3_ id) are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get Reddit post', 'Returns a normalized public Reddit post'), making clear it fetches a single post by id. It could differentiate more explicitly from siblings like reddit_comments or reddit_user_posts, but the singular 'post' framing is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to enable include_metrics (to obtain engagement metrics) and the credit trade-off, which is useful parameter-level guidance. However, it gives no sibling routing (e.g., 'use reddit_comments for the comment tree'), so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools