AIsa X / Twitter

Get List Tweet TimeLine

get_twitter_list_tweets_timeline

Read-onlyIdempotent

Get the tweet timeline of an X List by listId, up to 20 per page, cursor-paginated. Use this to monitor a hand-curated set of accounts as a single feed — Lists are the cheapest way to track a fixed cohort (competitors, analysts, a beat) without polling each account. Returns tweets with has_next_page and next_cursor. To see who is in the List use get_twitter_list_members.

Published reference price: $0.0015 USD per successful request. Account-specific pricing and final settlement may differ.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "listId": "<listId>"
    },
    "name": "get_twitter_list_tweets_timeline"
  }
}

Input Schema

Name	Required	Description	Default
`cursor`	No	Cursor for paginating through results. Leave empty for the first page.
`listId`	Yes	The list ID to get tweets from. e.g. 1846987139428634858

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026
- changedInput schema / required
```
Previous value: -[]New value: +[
+  "listId"
+]
```

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / cursor / description

Added value: +"Cursor for paginating through results. Leave empty for the first page."

addedInput schema / properties / listId / description

Added value: +"The list ID to get tweets from. e.g. 1846987139428634858"

Changed3 schema fields changedOct 15, 2026

removedInput schema / properties / cursor / description

Removed value: -"Cursor for paginating through results. Leave empty for the first page."

removedInput schema / properties / listId / description

Removed value: -"The list ID to get tweets from. e.g. 1846987139428634858"

changedInput schema / required

Previous value: -[
-  "listId"
-]New value: +[]

First observedSep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, and the description adds non-obvious operational detail: a 20-tweet page cap, cursor-based paging, and the presence of has_next_page/next_cursor in the response. The pricing note also flags that this is a metered call, which annotations do not convey.

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 tight sentences, ordered purpose → why-use-it → cross-reference, with the pricing boilerplate isolated at the end. No restatement of the title or name.

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 an output schema present, the description need not enumerate return fields, and it already names the pagination keys; annotations plus 100% schema coverage close the remaining gaps for a two-parameter read operation.

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 both listId and cursor are already documented with an example; the description still adds value by framing cursor as a paging control tied to a fixed 20-per-page batch, which the schema alone does not state.

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?

States a specific verb and resource ('Get the tweet timeline of an X List by listId') plus page size and pagination model in the first clause, which cleanly separates it from get_twitter_user_tweet_timeline and get_twitter_list_members.

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?

Gives a concrete use case ('monitor a hand-curated set of accounts as a single feed') and an explicit cost-based rationale versus polling each account, and points to get_twitter_list_members for the membership question. It stops short of stating exclusions, e.g. when to prefer get_twitter_user_tweet_timeline over a List feed.

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

All AIsa X / Twitter tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?