Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get the replies to an X post

xcrap_get_replies
Read-only

Fetch direct replies to an X/Twitter post, sorted by most liked or newest, with the original post included. Shows what people are saying, providing author, timestamp, text, and metrics for each reply.

Instructions

Fetch the replies under an X/Twitter post, most liked first or newest first, with the post itself on top.

This is how you answer "what are people saying about this post", "what did the replies think" or "find the strongest pushback on this". Only direct replies come back — a reply to a reply belongs to its own conversation.

When to use this instead of the alternatives:

  • Use xcrap_get_tweet if you only need the post.

  • Use xcrap_get_thread for the author's own follow-up posts; replies by other people are not a thread.

Args:

  • url (string, required): the post's URL or bare numeric id.

  • sort ('top' | 'recent'): 'top' (default) for the most liked first, 'recent' for the newest first.

  • format ('markdown' | 'json'): default 'markdown'.

Returns markdown: a "Replies to" heading, the post, then each reply with its author, timestamp, text and metrics. Returns json: { tweet_id, tweet_url, sort, count, tweet{...}, replies[ ] }.

There is no paging: this is the single page X serves for the post, up to about a hundred replies. Costs 20 calls/minute. A 404 means the post is deleted, private or never existed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe post whose replies to read: URL or bare numeric id.
sortNo'top' (default) for the most liked replies first, 'recent' for the newest first.top
formatNoOutput format. 'markdown' (default) is compact, human-readable and costs roughly a tenth of the tokens of the same data as JSON — prefer it for reading and summarising. Use 'json' only when you need exact field access: numeric ids, media URLs, per-metric values, or provenance metadata.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/destructive annotations, the description discloses meaningful runtime behavior: there is no paging, results are limited to roughly one hundred replies from the single page X serves, only direct replies are included, a 404 indicates the post is deleted/private/never existed, and there is a 20 calls/minute rate limit. All of this adds context the annotations cannot provide.

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 longer than strictly minimal but is well-organized: purpose, usage cues, sibling routing, args, return shapes, and constraints each have a clear section. The Args block partly repeats schema content, but the extra behavioral and return information justifies the length.

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?

Despite having no output schema, the description fully compensates by documenting return formats, limits, error semantics, sorting behavior, and rate limiting. Combined with the sibling guidance and parameter coverage, an agent has everything it needs to select and invoke this tool correctly.

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 covers all three parameters at 100%, so the baseline is 3. The description adds value for the format parameter by specifying exact markdown and JSON return structures, including the JSON field shape and token-cost rationale, which helps the agent choose and process the output correctly.

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?

States a specific verb and resource: 'Fetch the replies under an X/Twitter post, most liked first or newest first, with the post itself on top.' It also scopes the behavior precisely by noting only direct replies are returned and sets the tool apart from siblings like xcrap_get_tweet and xcrap_get_thread.

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

Usage Guidelines5/5

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

Explicitly gives when-to-use examples ('what are people saying about this post', 'find the strongest pushback on this') and names alternatives: use xcrap_get_tweet for just the post and xcrap_get_thread for the author's own follow-ups, adding that replies by other people are not a thread. This is model guidance.

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