SocialDataX X / Twitter MCP

x_search_posts

Read-only

按搜索词搜索 X / Twitter 公开帖子，只返回帖子结果。用户需要按搜索词查找帖子时使用；已有 post_id 或 post_url 时使用帖子详情或评论工具；已有 user_id、username 或 profile_url 时使用用户信息或用户帖子工具；支持 page_token 翻页和热门/最新排序。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keyword`	Yes	X / Twitter 帖子搜索词，可传关键词或短语，例如品牌名、话题、人物名或内容需求；不要传帖子链接、用户主页链接、接口地址、post_id、user_id、username 或 page_token。
`sort_type`	No	搜索排序：hot=热门，time_descending=最新；需要 latest/newest sorting 时也传 time_descending。如无明确排序需求，保持 hot。	hot
`page_token`	No	X 搜索分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一关键词和同一搜索排序链路；更换关键词或 sort_type 时，请清空 page_token 后从第一页重新搜索。

Output Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	当前页 X 搜索结果列表；已过滤掉用户、媒体页、列表等非帖子结果；当前页可能为空，是否可继续翻页以 next_page_token 是否为空为准。
`points`	Yes	本次成功调用的积分消耗与调用完成时的账户积分余额。
`next_page_token`	Yes	下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前搜索续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. Beyond that, the description adds the behavioral trait 'only returns post results' and mentions pagination and sorting, which are not in the annotations. This provides useful context that helps the agent predict behavior without additional inference.

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 a single, dense sentence that efficiently states purpose, usage, exclusions, and feature. It is front-loaded with the core purpose and then routes to alternatives, but the long sentence packs multiple clauses, which slightly reduces readability. Overall, it earns its place without redundancy.

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?

Given the presence of an output schema and detailed input schema parameters, the description covers all necessary aspects: purpose, usage conditions, exclusions, pagination, and sorting. Nothing essential for an agent to correctly invoke the tool 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?

Input schema covers 100% of the parameters with detailed descriptions, including exclusions for keyword and precise instructions for page_token. The tool description itself does not add any parameter-specific semantics beyond what the schema already provides. With full schema coverage, a baseline of 3 is appropriate.

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 clearly states the verb 'search' and the resource 'X / Twitter public posts', and explicitly notes it 'only returns post results', distinguishing it from sibling tools that return post details or user info. It differentiates itself by naming the exact conditions for using alternatives, so an agent can immediately identify the correct tool.

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?

The description provides explicit when-to-use and when-not-to-use guidance: it says to use when searching by keyword, and to use other tools when having post_id, post_url, user_id, username, or profile_url. It also mentions pagination and sorting support. This is thorough and leaves no ambiguity.

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

All SocialDataX X / Twitter MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools are clearly distinguished by resource, action, and identifier type (e.g., by_post_id vs by_post_url). The descriptions explicitly state when to use each, reducing ambiguity, but the high number of near-duplicate variants for user/posts/detail actions can still cause careful selection to be needed.

Naming Consistency4/5

The X tools follow a consistent pattern: x_get_<resource>_by_<identifier>, x_search_posts, and x_submit_x_by_<identifier>. The single socialdatax_get_points_balance tool uses a different prefix and pattern, creating a minor but noticeable inconsistency.

Tool Count4/5

16 tools is slightly above the ideal range, but the count is justified by the multiple identifier variants (ID, URL, username) for the same resource. Each tool maps to a specific input scenario, so the count feels intentional rather than bloated.

Completeness4/5

The server covers core X/Twitter read workflows: user info, user posts, post details, comments, comment replies, search, and the video speech text feature. Common gaps like followers/following or trending topics exist, but they are outside the apparent scope of the tool set and do not cause dead ends in the main use cases.

Resources

Need Help?