Short Answer: X MCP Costs Whatever the X API Costs
The official X MCP documentation describes X MCP as a hosted server at api.x.com/mcp that can call X API endpoints through an MCP client. That means the pricing question is really an X API pricing question, not a separate CarryFeed-style public viewer question.
X says the API uses pay-per-usage pricing with credits instead of a subscription. Reads are charged per resource returned, while writes and actions are charged per request. X also documents per-endpoint rate limits, so an agent can hit both cost controls and rate windows.
Docs MCP is different. It searches and reads X developer documentation. X MCP calls the API. If your assistant only needs documentation, do not confuse that with reading posts, users, bookmarks, or search results from X.
The agent needs authenticated X API tools, user context, bookmarks, Articles, search, or write actions.
The agent needs X API documentation, endpoint shapes, setup steps, or troubleshooting material.
The user already has a public X/Twitter URL and needs inspectable visible details for AI.
| Decision point | Official doc | What the docs say | Reader decision |
|---|---|---|---|
| What X MCP is | X MCP documentation | X MCP calls X API endpoints through api.x.com/mcp; Docs MCP searches and reads developer documentation. | Use X MCP for API work. Use Docs MCP for documentation lookup. |
| Whether X MCP costs money | X API pricing | X API is pay-per-use with no subscription; reads are charged per resource returned, writes/actions per request. | Budget by returned posts, users, and actions rather than by the MCP label. |
| Failed request billing | Usage and Billing FAQ | Failed reads that return no data do not count; successful reads that return data are billed. Successful writes and actions remain per-request operations. | Do not treat a failed no-data request as a cost driver, but still handle retries and 429s carefully. |
| Rate-limit planning | X API Rate Limits | Rate limits are per endpoint, expose limit/remaining/reset headers, and return 429 when exceeded. | Plan endpoint windows separately from billing. |
What Actually Creates Cost
The cost is not the MCP label. The cost comes from successful X API responses that return billable resources or from write/action requests behind the tool call.
The official X API pricing page lists Posts: Read at $0.005 per resource and User: Read at $0.010 per resource. It also lists Post: Create at $0.015 per request, Post: Create with URL at $0.200 per request, Bookmark at $0.005 per request, and Owned Reads at $0.001 per resource. Treat those rows as budget inputs beside the reads, writes, and source-handoff volume your agent actually needs.
X's usage and billing documentation also says pay-per-use plans are subject to a monthly cap of 2 million Post reads and that failed requests do not count when they do not return data. Billing is about successful returned resources; rate limits are about request windows.
| Operation | Official unit shown | Why it matters for MCP |
|---|---|---|
| Posts: Read | $0.005 per resource | Search, timeline, lookup, and stream tasks can return many posts. |
| User: Read | $0.010 per resource | Profile and user lookup tools are not free simply because an agent called them. |
| Owned Reads | $0.001 per resource | Some requests against your own app/user data can be priced differently. |
| Post: Create | $0.015 per request | Write-capable agents need explicit budget and permission controls. |
| Post: Create with URL | $0.200 per request | Automated posting with links is materially more expensive than a simple read. |
| Pay-per-use Post read cap | 2 million Post reads per month | High-volume search or monitoring jobs can hit plan-level limits before the task is done. |
| Failed requests with no data returned | Not billed under the Usage and Billing FAQ | A failed no-data response should drive retry/backoff handling, not a higher bill by itself. |
Quick Cost Scenarios Before You Build
These examples use the official unit prices. They are planning math, not a bill quote: deduplication, endpoint choice, returned resources, and the X pricing in effect at the time of use affect the estimate. Failed no-data requests are not billed under the official Usage and Billing FAQ.
The point is simple: an agent prompt can hide several API operations. A search may return posts, then the assistant may look up users, fetch individual posts, or write an output back to X. Budget those actions separately.
| Agent job | Simple planning math | What to decide first |
|---|---|---|
| Recent search returns 100 posts | 100 Post reads at $0.005 each = $0.50 before any extra lookups. | Do you need API discovery, or do you already have the source URLs? |
| Look up 25 user profiles | 25 User reads at $0.010 each = $0.25. | Does the task need profile lookup, or just the author shown on a known post? |
| Create one post that includes a URL | Post: Create with URL is listed at $0.200 per request. | Should an AI agent have write permission at all? |
| Read 1,000 owned resources that qualify for Owned Reads | Owned Reads are listed at $0.001 per resource = $1.00 for 1,000 resources. | Is this your own app/user data, or public data from other accounts? |
X MCP Is Still Rate Limited
Rate limits are separate from price. X's rate-limit page says limits are per endpoint and exposes response headers such as x-rate-limit-limit, x-rate-limit-remaining, and x-rate-limit-reset. When the limit is exceeded, the client receives a 429 until the window resets.
This is why a simple AI prompt like find the latest posts about this topic can become operationally messy. The agent may need recent search, user lookup, post lookup, timeline reads, and follow-up lookups. Each endpoint can have its own app and user window.
For content and research tasks, do not start with the highest-volume API path. Start from the known public source if you have one, keep the URL and visible details, and only escalate to API search when the user actually needs API-scale discovery.
| Endpoint | Per app | Per user | Practical meaning |
|---|---|---|---|
| GET /2/tweets/:id | 450/15min | 900/15min | Single-post lookup has a window even before billing is considered. |
| GET /2/tweets/search/recent | 450/15min | 300/15min | Keyword discovery through an agent must budget both query count and returned posts. |
| GET /2/tweets/search/all | 1/sec, 300/15min | 1/sec | Full-archive search needs queueing and backoff; it is not an unlimited free crawl. |
| GET /2/users/by/username/:username/tweets | 1,500/15min | 900/15min | Username timeline reads are listed separately under Other endpoints, so do not apply the ID endpoint number blindly. |
| GET /2/users/:id/tweets | 10,000/15min | 900/15min | The user-ID timeline endpoint has a different app window from the username timeline endpoint. |
Credentials and Scope Are the Real Boundary
X MCP is also not a no-account shortcut. The official MCP setup page says X OAuth requires your own developer app. The full route uses the xurl bridge with CLIENT_ID and CLIENT_SECRET, opens a browser for first-run OAuth login, caches tokens, and refreshes them.
There is also an app-only bearer route for read-only endpoints and a full OAuth route when the model needs to act with user scopes. That distinction matters for security: write-capable or user-context tools should not be enabled casually inside a general research agent.
A good default is to keep the API MCP disabled until the task needs it, and keep public-source tasks read-only. Most content tasks do not need an agent that can write to X or inspect authenticated user context.
| Route | What it needs | Use it when |
|---|---|---|
| Docs MCP | MCP client configuration pointing at docs.x.com/mcp | The agent needs X API docs, endpoint references, or setup instructions. |
| X MCP app-only bearer | X app bearer token passed as Authorization | The agent needs read-only API access without acting as a user. |
| X MCP through xurl bridge | Node/npx, X app OAuth 2.0, CLIENT_ID, CLIENT_SECRET, browser or headless login | The agent needs user-context tools, bookmarks, Articles, writes, or scoped actions. |
| CarryFeed public context | A public X/Twitter URL and human review | The agent only needs visible public details with the URL still attached. |
When a Public URL Is Enough vs When X MCP Is Needed
Use the smallest tool that can answer the user's actual question while keeping the original URL visible.
Avoiding X API credentials is honest only when the user already has a public source and does not need API discovery, authenticated account data, bookmarks, Articles, or posting. If the task needs those, use official X MCP or another official API path with credentials, budget controls, and rate-limit handling.
For public-source AI notes, the deeper checklist belongs in Twitter metadata for AI agents. The note should keep the original URL, visible text, author/date details, media rows, and unavailable states close to the model prompt.
| The user has or needs | Use first | Why |
|---|---|---|
| One public post, profile, media, search result, or article URL | CarryFeed | The source is already known. Keep the visible details and original URL before asking AI to reason over it. |
| Only a visual reminder for a personal note | Screenshot or manual copy | A tool is unnecessary if citation, media rows, and repeatable review do not matter. |
| A broad discovery task across X | Official X MCP or another official API path | Search and timeline discovery need API credentials, pricing, rate-limit handling, and query planning. |
| Bookmarks, Articles, user-context data, or posting | Official X MCP with strict permissions | This requires authenticated user scope and should not be handled by a public-source viewer. |
| A source that does not open from the shared URL | Mark unavailable | The useful handoff is the source state, not a reconstruction of missing text. |
| Endpoint syntax, OAuth setup, or implementation docs | Docs MCP | Documentation lookup does not require post reads or user-context API scope. |
Questions readers usually ask.
Does X MCP cost money?
X MCP itself is the MCP layer over the X API. When it calls X API endpoints, X API pay-per-use pricing applies. Build the budget from the API rows the agent will actually call: reads, writes, URL posts, bookmarks, owned reads, and any caps.
Is X MCP rate limited?
Yes. X API endpoint rate limits still apply. For example, the official rate-limit table lists separate app and user windows for post lookup, recent search, full-archive search, timelines, users, and other endpoints.
Does Docs MCP cost money?
Docs MCP is for searching and reading X developer documentation. It is different from X MCP calling API endpoints. The cost question in this article is about X API calls made through X MCP, not about reading documentation.
Can I use X MCP without an X developer app?
For real X API access, you need X developer credentials. The official X MCP setup describes an app-only bearer route and a full xurl bridge route that uses your X app CLIENT_ID and CLIENT_SECRET for OAuth.
When should I use CarryFeed instead of X MCP?
Use CarryFeed when the user already has a public X/Twitter URL and only needs visible public details, source URL, author/text/media notes, and a human-reviewable AI note. Use X MCP when the agent needs API search, authenticated data, bookmarks, Articles, or write actions.
Is CarryFeed an X MCP alternative?
Only when the job is turning a known public link into a reviewable source note. CarryFeed is not an official X API replacement and does not perform authenticated X actions. It is useful when API access is unnecessary because the user is working from known public links.
Can CarryFeed read private, protected, or deleted posts?
CarryFeed prepares known sources that open from the shared URL. If the URL does not open for the reader, mark that state in the source note instead of inventing text.
Can I avoid API credentials for a public post?
Only when you already have a public URL and just need visible source details. API search, bookmarks, user data, and posting still require official credentials, pricing awareness, and rate-limit handling.