Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List who follows an X account

xcrap_get_followers
Read-only

Fetch the list of accounts following a given X/Twitter handle, with names, bios, and follower counts. Paginate with next_cursor to retrieve more pages.

Instructions

Fetch one page of the accounts following an X/Twitter account, each with its name, handle, bio, follower count and verification.

Use this for "who follows @x", "who does @x follow", or to find the other accounts in someone's circle. X decides the page size (usually a few dozen accounts); pass next_cursor to continue, and stop when it is null.

When to use this instead of the alternatives:

  • Use xcrap_get_user for one account's own profile and follower count, rather than the list of accounts.

Args:

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

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

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

Returns markdown: a heading, then one line per account — name, handle, follower count — with its bio underneath, and a "Next page" cursor line when there is more. Returns json: { handle, relation, count, next_cursor, users[ ] }.

Costs 20 calls/minute. Protected accounts return 404; accounts that opted out of XCrap are left out of the list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from a previous call. Omit for the first page; never construct one by hand.
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
handleYesX handle, @handle or profile URL whose followers to list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses one-page pagination, next_cursor semantics, X-controlled page size, the 20 calls/minute rate limit, 404s for protected accounts, and omission of opted-out accounts. It also specifies the distinct markdown and JSON return shapes, giving agents concrete behavioral expectations.

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 organized into use-case, args, returns, and caveat sections, so its length is mostly justified by information content. It loses a point for repeating some schema/args details and including the inaccurate 'who does @x follow' phrasing, which makes it not perfectly lean.

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?

With three parameters and no output schema, the description supplies everything needed to call the tool correctly: required and optional argument semantics, pagination stop condition, return structures for both formats, rate limit, and known error/omission behavior. Nothing significant is missing.

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

Parameters3/5

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

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including accepted handle formats, cursor construction warnings, and the format enum tradeoffs. The Args section mostly restates that structured information, adding little parameter-level meaning beyond 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?

The opening sentence states a precise verb and object: 'Fetch one page of the accounts following an X/Twitter account' and lists the returned fields, so the core purpose is clear. It also names xcrap_get_user as a distinct alternative. However, the later line including 'who does @x follow' blurs the relation, since that phrasing describes xcrap_get_following rather than the follower list.

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 has an explicit 'When to use this instead of the alternatives' section that correctly routes single-profile/follower-count requests to xcrap_get_user. It also gives query phrasings and pagination guidance. Still, it tells agents to use this tool for 'who does @x follow' and never mentions the xcrap_get_following sibling, so the guidance is not fully reliable.

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