Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get an X post

xcrap_get_tweet
Read-onlyIdempotent

Fetch a single X/Twitter post by URL or numeric ID, returning full text, author, timestamp, engagement metrics, media, poll, quoted post, and community note without login.

Instructions

Fetch one post (tweet) from X/Twitter by URL or numeric id, including its full text, author, timestamp, engagement metrics, attached media, poll, quoted post and community note.

Works without any X account, API key or login, and reads posts that x.com refuses to show logged-out visitors. Long-form posts are returned in full, not truncated at 280 characters.

When to use this instead of the alternatives:

  • Use this for ONE specific post. It is the cheapest tool here (60 calls/minute).

  • Use xcrap_get_thread if the post is the start or middle of a multi-post thread and you want the whole thread unrolled.

  • Use xcrap_bulk for several posts at once — it is one call instead of N and has a far larger effective budget.

  • Use xcrap_list_media if you only need the image or video files attached to the post.

Args:

Returns (markdown): a heading with the author's name and handle, the timestamp and permalink, the post text, and a line of metrics (likes, reposts, replies, quotes, bookmarks, views). Returns (json): { id, url, text, lang, created_at, created_timestamp, author{...}, metrics{likes,retweets,replies,quotes,bookmarks,views}, media[], poll, quote, replying_to, replying_to_status, community_note, possibly_sensitive, is_note_tweet, entities[], client }.

Errors: 404 means the post is deleted, private or never existed and retrying will not help; 451 means the author opted out of XCrap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPost URL or bare numeric id. Accepts x.com, twitter.com and mirror hosts, e.g. "https://x.com/jack/status/20" or "20".
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.9/5.0
Behavior5/5

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

While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds significant behavioral context: it works without authentication, can read posts that x.com hides from logged-out visitors, and returns long-form posts without truncation. It also discloses the output structure for both markdown and JSON, plus error semantics. There is no contradiction with the annotations; the description enriches them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: it opens with a precise one-sentence purpose, then adds capability details, a targeted 'When to use' block, a clear Args list, a Returns section covering both output formats, and a compact Errors explanation. Despite covering many points, every sentence is useful and the structure makes it easy to scan. No redundancy or filler.

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?

For a read-only tool with no output schema, the description fully compensates: it specifies the return fields for both markdown and JSON, explains the error semantics (404 and 451), and provides throttling information (60 calls/min). It also covers the two parameters thoroughly. An agent has everything needed to call the tool correctly and interpret its response without external documentation.

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 (url and format) at 100% coverage. The description goes further by providing concrete examples for url (full URL, twitter URL, bare id) and by explaining the trade-offs of format: markdown costs a tenth of the tokens and is preferred for reading, while JSON is for exact field access. This adds practical meaning beyond the schema's enum and default.

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 clearly states the action ('Fetch one post (tweet) from X/Twitter by URL or numeric id') and enumerates the exact content returned (full text, author, timestamp, engagement metrics, etc.). It also distinguishes itself from sibling tools by explicitly naming xcrap_get_thread, xcrap_bulk, and xcrap_list_media with their different scopes, so an agent can immediately tell when this tool is the right one.

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?

The description contains a dedicated 'When to use this instead of the alternatives' section that lists concrete conditions for every relevant sibling: use for one specific post (cheapest at 60 calls/min), use xcrap_get_thread for unrolling a thread, use xcrap_bulk for multiple posts, and use xcrap_list_media for only media files. It also explains error codes (404 and 451) to prevent futile retries, which is actionable 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