Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get an X account timeline

xcrap_get_user_tweets
Read-onlyIdempotent

Fetch a page of a user's posts, newest first, with text, timestamps, and metrics. Use the returned cursor to paginate through their timeline.

Instructions

Fetch a page of an account's posts, newest first, with text, timestamps and metrics for each.

This is how you answer "what has @x been posting about", "find their recent posts about Y" or "what did they say this week". Paging is cursor-based because a timeline moves while you read it: pass the next_cursor from the previous call to get the next page.

When to use this instead of the alternatives:

  • Use xcrap_get_user for the profile and follower counts instead of the posts.

  • Use xcrap_get_thread when the posts you want are one connected chain rather than a general feed.

Args:

  • handle (string, required): "jack", "@jack" or a profile URL.

  • count (number, 1-100): posts per page, default 20. Above ~40 the result is likely to be truncated.

  • cursor (string): the next_cursor from a previous call, to fetch the following page. Omit for the first page. Do not invent one.

  • exclude_replies (boolean): default true — the account's own posts only. Set false to include its replies to other people.

  • media_only (boolean): default false. Set true for only posts carrying images or video.

Returns markdown: a "Posts by @handle" heading, the post count, then each post with its timestamp, permalink, text and metrics. To page further, call xcrap_get_user_tweets again with the cursor returned by XCrap.

Costs 20 calls/minute — one call returning 50 posts is far cheaper than 50 calls to xcrap_get_tweet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoPosts to return, 1-100 (default 20). Use 10-25 for reading; higher values risk truncation.
cursorNoPagination cursor from a previous call. Omit for the first page; never construct one by hand.
handleYesX handle, @handle or profile URL whose timeline to read.
media_onlyNoReturn only posts with attached images or video (default false).
exclude_repliesNoExclude the account's replies to other people (default true). Set false to include them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent behavior, and the description adds substantial behavioral context beyond that: cursor-based paging justified by a moving timeline, truncation risk above ~40 posts, the markdown return format, and a 20 calls/minute rate limit with cost comparison to xcrap_get_tweet. 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.

Conciseness5/5

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

The description is front-loaded with the core purpose, then organized into crisp sections for paging rationale, alternative selection, parameter semantics, return format, and cost. Every sentence contributes useful decision or invocation information without fluff.

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 explains the return value in detail ('a 'Posts by @handle' heading, the post count, then each post with its timestamp, permalink, text and metrics'), covers all five parameters, paging, rate limits, and sibling routing. An agent has everything needed to select and call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description still adds material meaning: handle accepts 'jack', '@jack' or a profile URL; count has a practical truncation threshold; cursor must come from a previous call and must not be invented; exclude_replies default behavior and media_only purpose are clarified. This goes well beyond the baseline schema descriptions.

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 opens with a specific verb and resource: 'Fetch a page of an account's posts, newest first, with text, timestamps and metrics for each.' It clearly distinguishes itself from siblings by naming xcrap_get_user for profile data and xcrap_get_thread for connected chains, leaving no ambiguity about what this tool does.

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?

Usage guidance is explicit and actionable: it gives concrete question patterns like 'what has @x been posting about' and states alternatives with when to choose them ('Use xcrap_get_user for the profile and follower counts instead of the posts'). It also explains paging behavior and when to pass a cursor.

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