Skip to main content
Glama

x_user_followers_ids

Get follower IDs. Follower user IDs only, 200 per page. Pass either userName or userId. Paginated: use cursor / next_cursor.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "x_user_followers_ids"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNoPagination cursor. Leave empty for the first page, then pass `next_cursor` from the previous response.
userIdNoNumeric user ID, e.g. `11348282`.
userNameNoScreen name without the @, e.g. `NASA`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose two genuinely behavioral facts beyond the schema: results are IDs only and capped at 200 per page with cursor pagination. It is silent on auth requirements, rate limits, ordering, and error behavior for a nonexistent or protected user.

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?

Three compact sentences, front-loaded with purpose, then payload shape and page size, then identification and pagination rules. No filler and nothing repeated from the schema verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter read tool with no output schema and no annotations, the definition covers identification and pagination adequately. It does not clarify what the response envelope looks like (e.g., whether `next_cursor` is absent or null on the last page), which matters when no output schema exists.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by stating that `userName` and `userId` are alternatives ("pass either"), which the schema's zero required parameters leaves ambiguous. It does not explain precedence if both are passed.

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?

States a specific verb and resource (get follower IDs) and immediately narrows scope with "Follower user IDs only, 200 per page," which distinguishes it from a full user-object followers endpoint like x_user_followers. It does not name that sibling explicitly, so differentiation is implied rather than stated.

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?

Gives concrete invocation guidance: pass either `userName` or `userId`, and paginate with `cursor` / `next_cursor`. It does not say when to prefer this over the richer followers endpoint or what happens if both identifiers are supplied, so usage context is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources