--- title: MCP Big Picture: How Servers, Clients, and Host Apps Fit Together description: How MCP clients, servers, and host applications connect. Covers the feature matrix across Claude Desktop and Cursor, and why tools get the broadest compatibility today. author: FractionalSkill ---

MCP Big Picture: How Servers, Clients, and Host Apps Fit Together

You have seen the diagram. Host apps at the top, MCP servers below them, external services at the bottom. But seeing the diagram is different from understanding why each piece exists and what choices each one makes. This guide closes that gap.

What host applications actually do

A host application is any AI-powered app that wants to connect to MCP servers. Claude Desktop, Cursor, Windsurf -- these are host apps. The LLM lives inside the host app. Your conversation happens inside the host app.

For a host app to support MCP, its developers have to build in MCP client support. That is an intentional engineering decision, not automatic. It means adding the protocol layer that lets their app talk to any MCP server in the community.

Once a host app implements that client support, every MCP server becomes potentially compatible with it. That is the compounding value. Developers build servers for any app that supports the standard. Users of every compatible app benefit.

Build once, use anywhere is not marketing language. It is the operational consequence of standardization. An MCP server you configure for Claude Desktop is already usable in Cursor without any changes.

What clients choose to support

MCP servers can expose three types of capabilities: tools, resources, and prompts. But each client gets to decide which of those capabilities it wants to implement. This is where it gets practical.

Tools are LLM-controlled actions. The model decides when to call them based on your request. A "get forecast" tool in a weather server, a "create task" tool in a Linear server -- these are tools. Tools are supported across virtually every major MCP client right now.

Resources are user-controlled context. You explicitly add them to a conversation. A list of open issues from Linear, the contents of a project folder -- these could be resources. Claude Desktop supports resources. Cursor currently does not.

Prompts are reusable templates stored in the server. In Claude Desktop, you access them through a separate prompt panel -- click the plug icon, fill in template variables, and Claude gets a structured prompt injected into context. Cursor does not support prompts.

This means a server feature you build might work in one client but not another. That is a real constraint, not an edge case. If you build a prompt template into an MCP server, it works in Claude Desktop. It does not appear in Cursor at all.

> Start with tools. They have the broadest client compatibility right now. Resources and prompts add real value in Claude Desktop specifically, but if you are building servers for your own workflow and you use multiple AI apps, tools are what work everywhere.

Where to find servers

The MCP GitHub repository maintains a servers list that is worth bookmarking. It includes official servers from companies like Stripe alongside community-built servers for dozens of popular tools.

What is worth understanding is that these servers are open source. You can read the code for any of them. If you want to understand how a particular server implements a tool or handles authentication, the source is right there. It is also one of the best learning resources available -- better than documentation alone, because you can see working patterns directly.

Companies shipping official MCP servers include both large platforms and AI-native startups. BrowserBase, Exa, and Firecrawl have servers available. Stripe has an official server. The list is growing quickly.

How clients and servers combine

The real power of the MCP architecture is in the combinations. A single host app can connect to as many MCP servers as you configure. The LLM inside that host app then decides which tools to call based on what you ask.

A practical example: a Cursor session connected to a Linear server, a GitHub server, and a filesystem server simultaneously. Ask Cursor to pull the open tickets assigned to you, find the corresponding files in your codebase, and draft a plan. It can reach across all three servers to answer that.

You are not switching between apps to gather context from each one. The LLM decides which tools are relevant to your request and calls them in sequence. The servers handle the actual connections to each service.

You (in Cursor Agent)
       │
       ▼
  Cursor (host app with MCP client)
       │
   ┌───┼───────────────┐
   │   │               │
   ▼   ▼               ▼
Linear  GitHub      Filesystem
server  server       server
   │   │               │
   ▼   ▼               ▼
Linear  GitHub    Local folders
 API    API

That combination is available now. As more clients implement the full MCP feature set and more servers get published, the number of possible combinations grows without anyone having to rebuild anything.

> Where MCP is headed. Remote server hosting with OAuth authentication is on the MCP roadmap. When that lands, connecting to a service like Slack could be as simple as adding a URL to your config and authenticating once -- no local server to install or maintain. For now, most servers run locally, but the infrastructure is being built for what comes next.