X Research MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Host interface for the optional HTTP server. | 127.0.0.1 |
| MCP_PORT | No | Port for the optional HTTP server. | 8766 |
| PUBLIC_BASE_URL | No | Exact HTTPS origin used for remote host/origin validation when serving behind an HTTPS ingress. | |
| X_MCP_STATE_DIR | No | Directory for state storage. Defaults to the OS user-data directory with folder name 'bk927-x-mcp'; use a dedicated directory. | |
| MCP_ACCESS_TOKEN | No | Bearer token for HTTP authentication. Mandatory when binding outside loopback. | |
| X_MCP_RESULT_TTL | No | Time-to-live for stored results in seconds. Configurable between 60 and 86400. | 3600 |
| X_MCP_SESSION_FILE | No | Path to the session file inside the state directory. | session.json |
| X_MCP_MAX_RESULT_BYTES | No | Maximum normalized payload size in bytes. Configurable between 4096 and 32768. | 12288 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| x_searchA | Search public X posts or users. Prefer small pages; results are not exhaustive. Continue with identical query and cursor. |
| x_post_getA | Read a public post by ID/URL, its author thread, replies, quotes, or reposters. Long text can be recovered from its result_id. |
| x_user_getA | Read a public profile or a page of posts, posts with replies, media, articles, followers, or following. Accepts @handle/profile URL. |
| x_collection_getA | Read public list/community posts or members; community info is also supported. Requires a session and explicit public visibility proof. |
| x_trends_getB | Read provider-context trends. Geography is unknown unless supplied by the source; news/sport/entertainment require a session. |
| x_analyzeA | Aggregate saved public post results: activity, engagement, link domains, hashtags. No new network fetches or LLM inference; sample statistics only. |
| x_result_getA | Read saved results without network. Set item_id for full text chunks, or field=json for lossless object chunks. source_cursor resumes the original query tool. |
| x_statusA | Inspect capabilities/configuration or recorded provider health. view=schema with tool=NAME returns that tool's input rules. Does not make live probes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| capabilities | Configured public research capabilities; no live probing. |
TDQS
Scored across 8 tools
Each tool targets a clearly distinct data surface: search, post, user, collection, trends, saved-result analysis, raw saved-result retrieval, and server status. x_analyze and x_result_get both operate on saved results, but one computes aggregates while the other returns raw stored chunks, so an agent should not confuse them.
Most tools follow an x_<resource>_get pattern: x_post_get, x_user_get, x_collection_get, x_trends_get, and x_result_get. The exceptions are x_search, x_analyze, and x_status, which break that resource-get convention, but the shared x_ prefix and lowercase snake_case keep the naming mostly predictable.
Eight tools is well-scoped for a read-only X research server. Each tool serves a distinct need, and none feel redundant or excessive for the stated purpose.
The tool surface covers search, post/user/collection/trends reads, saved-result access, and aggregation, which supports the research workflow well. Minor gaps such as no explicit saved-result listing/deletion or batch operations can be worked around by repeated calls or using existing saved-result access.