Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List who an X account follows

xcrap_get_following
Read-only

Retrieve a page of accounts followed by an X/Twitter profile, including name, handle, bio, and follower count. Use it to discover who someone follows, with pagination via next_cursor.

Instructions

Fetch one page of the accounts followed by 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 following to list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior5/5

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

The description adds meaningful behavior beyond the annotations: this is a one-page fetch, X decides the page size, continuation uses a cursor, the cursor must come from prior results and stops at null, protected accounts have a 404, opted-out accounts are omitted, and the rate limit is 20 calls/minute. All of this is genuine behavioral detail that cannot be inferred from readOnlyHint/openWorldHint.

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 organized clearly with purpose first, then use context, alternatives, args, return values, and operational notes. It is somewhat longer than needed and the 'Args' section duplicates schema field details, but the content is informative, scannable, and sections are labeled. This is efficient communication rather than rambling.

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?

Without an output schema, the description fully explains the markdown and JSON return shapes, the pagination termination condone, and the conditions under which accounts may be missing or errors (404, opted-out accounts). It also states the rate limit. An agent has enough information to invoke the tool correctly and understand each response field.

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?

Input schema descriptions cover all three parameters in detail, so the baseline is 3. The description restates handle forms ('jack', '@jack', URL) and cursor use, but most of these details already exist in the schema. It does reinforce the 'don't invent a cursor' rule and adds a friendly type for format, but the value added beyond the schema is minimal.

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 core sentence says exactly what is done: 'Fetch one page of the accounts followed by an X/Twitter account', with the specific data fields and the account's own list one-page scoping. The reference to xcrap_get_user as an alternative helps distinguish it from profile lookup. The only issue is the later example 'who follows @x' colloquially points to followers, but the core purpose is still 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?

It gives concrete example queries and correctly suggests xcrap_get_user when you need the account's own profile/follower count. However, it never mentions the sibling xcrap_get_followers, and while 'who follows @x' in the description actually points toward the follower direction rather than the following direction. This leaves an agent without explicit guidance to choose between this tool and xcr_transform_get_followers, which is the main sibling confusable.

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