What Is an MCP Server? How AI Clients Talk to It, With a Live Twitter (X) Example

The Model Context Protocol is an open protocol for connecting LLM applications to external data and tools. The specification names three roles. Hosts are the LLM applications that start connections, for example Claude Code, Claude Desktop, Cursor, Codex or ChatGPT. Clients are connectors inside the host. Servers are the services that provide context and capabilities. All three speak JSON-RPC 2.0, and the spec says MCP takes its inspiration from the Language Server Protocol, which did the same job for programming-language support in editors.

The architecture page on modelcontextprotocol.io spells out the cardinality: a host connects to one or more MCP servers by creating one MCP client for each server, and each client keeps a dedicated connection to its server. So when Claude Code shows five connected servers, it is running five clients side by side, each with its own transport, its own list of tools and its own credentials.

The practical meaning of "MCP server" follows from that. It is the thing you install or point your AI app at so the model can do something it could not do from its training data alone: search tweets, query a database, read a repository, file a ticket. The server describes each capability in a machine-readable way, the host shows those descriptions to the model, and when the model decides to use one the client sends the call and hands the result back.

MCP server vs API. A REST API is built for programmers: you read the docs and write the request. An MCP server is built for a model: every tool carries a natural-language description and a JSON Schema for its arguments, and discovery is part of the protocol (tools/list), so any compliant host can use any compliant server without integration code. Many MCP servers, including the one used as the example here, are thin wrappers that turn existing REST endpoints into tools.

The meaning that is not this one. Search results for "MCP server" also surface Minecraft protocol servers and several invented expansions of the acronym. In AI tooling, MCP means Model Context Protocol, the specification maintained at modelcontextprotocol.io.

The specification lists three server features. Each is a family of JSON-RPC methods, and a server declares which families it supports in its capabilities.

In practice tools carry most of the weight. In our X sample, the word "tool" or "tools" appeared in 25.2% of posts that mention an MCP server, while "resource(s)" or "prompt(s)" appeared in 7.9%. The worked example follows the same pattern: TwitterAPI.io's hosted server declares only the tools capability, and its resources/list and prompts/list both return JSON-RPC error -32601 (method not found), which is the correct answer for a feature a server does not offer.

Clients can offer features back to servers. The current revision lists elicitation, where a server asks the user for more input. The same revision deprecates Roots, Sampling and Logging and suggests replacements: pass directories through tool parameters or server configuration instead of Roots, call an LLM provider API directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging.

Tools can also carry annotations that describe their behavior. Every tool on the example server is marked readOnlyHint: true and openWorldHint: true, meaning it does not change state and it reaches an external system. The spec warns that hosts should treat annotations as untrusted unless the server itself is trusted, and that hosts must get explicit user consent before invoking any tool.

Protocol semantics are identical on every transport; the transport only defines how messages are framed and delivered. The current spec defines two standard bindings, and every client config you will see maps to one of them.

stdio. The client launches the server, writes requests to its stdin and reads responses from its stdout. Messages are newline-delimited and must not contain embedded newlines; the server must not write anything to stdout that is not a valid MCP message, which is why a stray print() in a Python server breaks the connection. Shutdown is closing the stream. The spec also notes that the same framing works over Unix sockets or TCP.

Streamable HTTP. The server exposes a single endpoint that accepts POST. The client must send an Accept header listing both application/json and text/event-stream; a notification gets 202 Accepted with no body, and a request gets either one JSON object or a request-scoped SSE stream. Cancellation is closing that stream. The older HTTP+SSE transport, deprecated since protocol version 2025-03-26, is now formally on the removal path, and the 2026-07-28 revision also drops the separate GET stream endpoint.

How the clients name these: Claude Code adds remote servers with claude mcp add --transport http <name> <url> and local ones with --transport stdio followed by -- and the command; its docs note that streamable-http is accepted as an alias of http in JSON config, and that a JSON entry with a url but no type is read as stdio and skipped. Cursor's mcp.json uses command/args/env for stdio and url/headers for remote servers, at ~/.cursor/mcp.json globally or .cursor/mcp.json per project. Codex uses [mcp_servers.<name>] tables in ~/.codex/config.toml with command for stdio, or url plus bearer_token_env_var or http_headers for Streamable HTTP.

Which to choose. stdio is simplest when the server needs your local files or a local process, and it keeps secrets on your machine. Streamable HTTP is the only option for hosts that cannot launch processes (ChatGPT on the web, for example) and lets one server serve many users. On X the split in conversation is close: 10.4% of the sampled posts mention stdio, local or npx, and 8.2% mention HTTP, remote or hosted servers; the deprecated SSE transport came up in 0.1%.

Every protocol revision up to and including 2025-11-25 opens a connection with a handshake. The client sends initialize with the protocol version it wants and its capabilities; the server replies with the version it will speak, its own capabilities, its identity and optional instructions for the model; the client confirms with notifications/initialized. Only then does it list and call tools.

We ran that sequence against TwitterAPI.io's hosted server with curl, with no API key. The full exchange is below. Two details are worth noticing. When we asked for the newer 2025-11-25 revision, the server answered 2025-06-18, which is version negotiation working as designed: the server picks the newest revision it supports. And the instructions field tells the model how authentication works, so an agent that reads it can tell the user what to paste where.

The median wall time of five initialize round trips from our probe machine was 1.14 seconds. That is a single location and says nothing about the server's capacity; it does show why hosts keep connections warm instead of re-handshaking per call. The server also did not issue an Mcp-Session-Id header, so it keeps no per-connection state.

The current protocol version on modelcontextprotocol.io is 2026-07-28, and it changes the picture above in ways most explainers have not caught up with. The changelog lists the major changes; these are the ones that matter for anyone connecting or running a server.

Stateless requests. The initialize / notifications/initialized handshake is gone. Every request carries its protocol version and the client's capabilities in _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities), and on HTTP the version is mirrored in the MCP-Protocol-Version header. A server that does not support the requested version answers UnsupportedProtocolVersionError (code -32022) with the list it does support.

No sessions. The Mcp-Session-Id header and protocol-level sessions are removed from Streamable HTTP. Servers that need state across calls mint explicit handles and pass them as ordinary tool arguments.

server/discover is mandatory. Servers must implement it to return their supported versions, capabilities and identity in one call; clients may call it first or simply send requests and handle a version error.

Other removals. ping and logging/setLevel are removed, the GET stream and resources/subscribe are replaced by a single subscriptions/listen stream, SSE resumability is removed, and server-initiated requests are replaced by a multi round-trip pattern in which the server returns an input_required result and the client retries with the answers. Streamable HTTP POSTs must also carry Mcp-Method and, for tools/call, resources/read and prompts/get, an Mcp-Name header.

Old and new side by side. The spec calls revisions up to 2025-11-25 "legacy" and 2026-07-28 onward "modern". Its compatibility matrix says a modern-only client and a legacy-only server fail to connect, a legacy-only client and a modern-only server also fail, and dual-era implementations work with both by falling back to initialize when the modern request is rejected.

Our example server is on the legacy side today. A server/discover request with modern _meta and headers got -32601 (method not found); a modern-style tools/list with no prior handshake was still answered with all 12 tools, because the server keeps no session. We report what we observed, not a promise about its roadmap. If you build a client, the spec's advice applies: detect the server's era once per origin and cache it.

This is what a modern request looks like, taken from the server/discover page of the specification:

The worked example is a real server you can connect now. It reads public X data through 12 tools (search_tweets, get_user_info, get_user_about, get_user_followers, get_user_followings, get_user_last_tweets, get_user_mentions, get_tweets_by_ids, get_tweet_replies, get_tweet_quotes, get_tweet_retweeters, get_trends). No X account or X developer approval is needed for reads; you need a TwitterAPI.io key, and new accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days).

Step 1, the key. Sign in at twitterapi.io/dashboard and copy the API key. Keep it in an environment variable rather than in a config file you might commit.

Step 2, the client. Pick the block for your host below. The hosted server's own instructions say to send the key as a Bearer token, and TwitterAPI.io's Cursor docs use Authorization: Bearer ${env:TWITTERAPI_IO_API_KEY}; the server also accepts an X-API-Key header. If you prefer a local process, the open-source package @twitterapi_io/mcp-server (MIT, version 0.2.0 on npm) runs the same tools over stdio and reads the key from TWITTERAPI_IO_API_KEY.

Step 3, ask. Start a new session and ask something like "what are people saying about MCP servers today, in English, latest first". The model picks search_tweets with queryType: Latest, most hosts ask you to approve the call before it runs, and the answer is built from the posts the tool returns.

ChatGPT. ChatGPT on the web cannot launch local processes, so it only takes remote servers. OpenAI's help center describes custom MCP server connections for Business and Enterprise/Edu workspaces, added from the Plugins page; the step-by-step for this server, including the OAuth sign-in, is on /blog/chatgpt-mcp.

A note on context. Every tool definition is loaded into the model's context before the first call, so tool lists have a cost even when unused. The chart below breaks down the example server's list.

Across all 12 tools there are 32 parameters, 12 of them required, in 11,390 bytes; at the common rule of thumb of about four characters per token that is roughly 2,848 tokens, though the real count depends on the model's tokenizer. search_tweets is the heaviest because its description teaches the model the X search operators and when to prefer it over get_user_last_tweets.

To see how the term is used in the wild, we pulled the 1,099 most recent posts on X containing "mcp server" (retweets excluded), covering 39.1 hours, about 28.1 posts an hour. 31.6% name at least one AI client. Claude dominates, and Claude Code alone appears in 10.8% of posts; Cursor, Codex and ChatGPT/OpenAI are bunched together just above 8%.

The conversation is practical. 19.5% of posts are questions, 34.8% are replies, 10.1% carry a github.com link (usually a server someone published) and 32.4% include an image or video. Authentication comes up more than transports: 15.7% mention OAuth, API keys, auth or tokens, and 7.9% mention security, prompt injection, vulnerabilities or malicious servers.

Reach is thin for most posts: the median post had 1 like and 55 views, while the top tenth reached 14 likes and about 894 views. 89.8% of posts are in English; the next largest groups are posts with no linguistic content (links or media only, tagged zxx, 4.3%), Chinese (2.7%) and Japanese (1.3%).

The protocol is free; the server's backend is what you pay for. With the example server, each tool maps to a TwitterAPI.io endpoint and is billed like a direct call: tweet endpoints are 15 credits per tweet returned, which is $0.15 per 1,000 tweets, with a 15-credit minimum per request, and profiles are 18 credits per user, $0.18 per 1,000. One full 20-tweet search page costs $0.003. You pay only for the data returned; purchased credits never expire.

The official figures are from the X API pay-per-usage rate card at docs.x.com/x-api/getting-started/pricing, read for this article; at $5 versus $0.15 per 1,000 posts the official rate is about 33 times higher. X also gives $20 of credits on a first card and matches a first auto-recharge up to $50. Our own sample of 1,099 posts cost about $0.16 to collect. TwitterAPI.io rate limits are 0.2 requests per second before the first payment and 20 once paid, with higher limits on larger plans; subscriptions and volume pricing are on /pricing.

Treat every server as code you are running. The spec says tools represent arbitrary code execution, that hosts must obtain explicit consent before invoking any tool, and that hosts must not send resource data elsewhere without consent. In practice: install servers from sources you can read, keep keys in environment variables, give each server the narrowest credentials it needs, and read tool descriptions before approving them, because a description is text the model will follow.

Watch what comes back. A server that reads public content, such as posts on X, returns text written by strangers. That text lands in the model's context, which is the route for prompt injection. Keep write-capable servers separate from read servers, and keep human approval on for any tool that changes state.

Writes are separate. The example MCP server only reads. TwitterAPI.io does offer write actions over REST: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, and each post, like, retweet or follow through endpoints such as /twitter/create_tweet_v2 is then 60 credits ($0.0006), billed per HTTP 200 call. Those calls act as that account, so X can rate-limit, lock or suspend it; keep a human pace, and expect the session to need a re-login now and then.

Question. Which AI clients and connection terms appear next to "MCP server" in recent X posts, and what does a real hosted MCP server return on the wire?

X sample. 55 requests to /twitter/tweet/advanced_search with the query "mcp server" -filter:retweets, queryType=Latest, returning 1,099 unique posts spanning 39.1 hours, collected in 2026. Clients and terms were matched with fixed keyword lists on lower-cased post text (the lists are in the study's analyze.py); a post can match several, and "local" and "token" are broad words, so treat the transport and auth shares as upper bounds.

Server probe. Fourteen HTTP requests with curl to mcp.twitterapi.io/mcp without an API key: initialize at two versions, notifications/initialized, tools/list in both styles, resources/list, prompts/list, ping, server/discover, an unauthenticated tools/call, a GET, and five timed initialize calls. The raw initialize, tools/list and server/discover responses are saved with the study.

What it cannot show. A 39-hour window of the latest posts is a snapshot, not a trend; it overweights whatever shipped that day. Keyword matching misses posts that mention a client by a nickname or only in an image. The probe measured one server from one location; its latency says nothing about other servers or regions. We did not call any tool with a key, so the tool-call result shape on this page comes from the specification.

Privacy. The authors of the sampled posts are private individuals. We publish aggregates only; raw search pages were not kept with the study, and the de-identified rows hold no IDs, URLs, post text or handles.