Problem
Agent Native supports custom remote MCP servers, but its built-in catalog has no X data integration. A user who asks to connect Xquik for X post search gets no preset. They must already know the endpoint and its authentication model.
The existing twitter provider API uses twitterapi.io with an API key. This proposal would not replace it. It would add a separate, user-authorized MCP connection for agent workflows.
Proposed scope
I propose a built-in Xquik preset with:
https://xquik.com/mcp as the Streamable HTTP endpoint
- OAuth connection mode with user scope
preflight-only verification, matching the unauthenticated endpoint response
- Exact Xquik prompt matching, plus focused catalog keywords for X post search, profiles, timelines, and monitoring
- Catalog, filtering, prompt-matching, uniqueness, and metadata tests
- Localized description, use case, and setup guidance
- A changeset and any required documentation updates
I would avoid a bare X prompt alias because it would create false positives. I would also keep organization scope disabled until its sharing semantics are verified.
Verification
I checked the live endpoint on August 23, 2026. An unauthenticated MCP discovery request returns 401 with protected-resource metadata for https://xquik.com/mcp and the mcp:tools scope. The authorization server publishes dynamic client registration, authorization-code and refresh-token grants, and S256 PKCE. The public server card identifies the endpoint as Streamable HTTP.
Public references:
Disclosure
I maintain Xquik. I would use only its published contracts and public assets. Xquik is an independent third-party service and is not affiliated with X Corp.
Would this catalog boundary be acceptable before I create a fork and implementation?
Problem
Agent Native supports custom remote MCP servers, but its built-in catalog has no X data integration. A user who asks to connect Xquik for X post search gets no preset. They must already know the endpoint and its authentication model.
The existing
twitterprovider API uses twitterapi.io with an API key. This proposal would not replace it. It would add a separate, user-authorized MCP connection for agent workflows.Proposed scope
I propose a built-in Xquik preset with:
https://xquik.com/mcpas the Streamable HTTP endpointpreflight-onlyverification, matching the unauthenticated endpoint responseI would avoid a bare
Xprompt alias because it would create false positives. I would also keep organization scope disabled until its sharing semantics are verified.Verification
I checked the live endpoint on August 23, 2026. An unauthenticated MCP discovery request returns
401with protected-resource metadata forhttps://xquik.com/mcpand themcp:toolsscope. The authorization server publishes dynamic client registration, authorization-code and refresh-token grants, and S256 PKCE. The public server card identifies the endpoint as Streamable HTTP.Public references:
Disclosure
I maintain Xquik. I would use only its published contracts and public assets. Xquik is an independent third-party service and is not affiliated with X Corp.
Would this catalog boundary be acceptable before I create a fork and implementation?