Skip to content

What is MCP? A plain-English guide for app builders

By Chris Artmann ·

You've probably seen "MCP" everywhere by now. In changelogs, in tweets, in the settings of every AI app you use. Most explanations either stay very abstract or dive straight into the spec. So let's do it differently. We'll follow one real question from a chat window to a server and back, and by the end you'll know what MCP is and whether you need it.

The question is one we hear a lot: "What can I cook with chicken and rice?"

Ask a plain chatbot and it answers from memory. It'll suggest a stir fry, maybe a biryani. The amounts are guesses. It has no idea what's actually in a recipe database, or what you're allergic to. It's a nice chat, but it isn't connected to anything real.

MCP is how you connect it.

The problem MCP solves

Before MCP, every AI app had its own way of plugging in outside tools. ChatGPT had plugins. Other apps had their own function-calling formats, their own manifest files, their own auth. If you ran an API and wanted it to work in five AI apps, you built five integrations. And every app builder had to write a connector for every service they wanted to support.

The Model Context Protocol is an open standard that fixes this. Anthropic released it in late 2024, and since then OpenAI, Google, Microsoft and most coding tools have adopted it. You build one MCP server for your service, and any app that speaks MCP can use it. People like to call it "USB-C for AI apps". That's a bit of a cliché, but it's accurate.

There are three parts to know:

  • The host is the app you're chatting in. Claude, ChatGPT, Cursor, VS Code.
  • The client lives inside the host. It keeps one connection open to one server.
  • The server is the thing that wraps a real service. A recipe database, your calendar, a GitHub repo.

Here's our question making the round trip:

You: "What can I cook with chicken and rice?"
  │
  ▼
Host (Claude, ChatGPT, Cursor…)
  │  the model sees a tool called cook_from_pantry
  │  and decides to call it
  ▼
MCP client ──── JSON-RPC ────▶ MCP server (Tiny Plates)
                                  │
                                  ▼
                               GET /pantry?ingredients=chicken,rice
                                  │
MCP client ◀─── tool result ──────┘
  │
  ▼
The model reads real recipes and answers you

When the host connects, it asks the server what it can do. The server replies with a list of tools. Each tool has a name, a description written for the model, and a JSON schema for its inputs. Our server lists nine, and one of them is cook_from_pantry. Its description starts like this:

Find what you can cook from the ingredients you have, best covered first. Each recipe lists the pantry ingredients it uses and the ones you are missing.

That description is the whole trick. The model reads it, sees that it fits your question, and calls the tool. Under the hood the call is a small JSON-RPC message:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "cook_from_pantry",
    "arguments": {
      "ingredients": ["chicken", "rice"],
      "maxMissing": 2
    }
  }
}

The server turns that into a normal API request and sends back the result. Each recipe comes with its real ingredient list, plus three handy fields: matchedIngredients (what you have), missingIngredients (what you'd need to buy) and assumedIngredients (staples like salt and oil that we assume you own). The model reads that and writes its answer. Now the amounts are real, and so are the recipes.

You never see any of this. You just get a better answer. And it's worth noticing how little the model did on its own. It picked a tool and filled in two arguments. The data came from somewhere real.

Tools, resources and prompts

Tools get all the attention, but an MCP server can offer three kinds of things. The easiest way to tell them apart is to ask who decides when they're used.

Tools are chosen by the model. They're actions: search recipes, build a shopping list, create a ticket. The model calls them when it thinks they'll help.

Resources are chosen by the app. They're things to read, like a file, a database row or a document. The host decides when to pull them into the conversation, often because you attached one.

Prompts are chosen by you. They're ready-made templates, often shown as slash commands. Think "/plan-my-week" with the right instructions already filled in.

Most servers today are mostly tools, and ours is all tools. That's fine. Start with tools and add the others when you have a reason.

MCP also runs in two ways. A local server runs on your machine and talks over stdin and stdout. It's great for things like your file system or a local database. A remote server runs on the web and talks over HTTP. That's what you want for a real service, because nobody has to install anything. Remote servers need auth, though. MCP uses OAuth for that, so you sign in once in a browser window and never paste an API key into a config file. That's how our server works. You add the URL, sign in with your Tiny Plates account, and you're done.

So where can you use all this today? Pretty much everywhere. Claude supports MCP in the desktop app, on claude.ai as custom connectors, and in Claude Code. ChatGPT supports remote MCP servers as connectors. Cursor, VS Code, Windsurf, Zed, Codex and Gemini CLI all speak it too. If you build one server, it works in all of them.

Now for the honest part. You don't always need MCP. If you're building your own app with one model and a handful of functions, plain function calling is simpler. You define the tools in your code and handle the calls yourself. MCP shines when you want your service to work in other people's AI apps. It also helps when you want one integration to work across many hosts. Building a SaaS? An MCP server is quickly becoming as normal as having a REST API. Building a single chatbot? Function calling might be all you need.

If you want to see it working, the quickest way is to connect a real server and ask it something. Ours is free to try. In Claude Code, it's one line:

claude mcp add --transport http --scope user tinyplates https://api.tinyplates.dev/mcp

Then ask "What can I cook with chicken, rice and a lime?" and watch the tool calls go by. The MCP docs have one-click installs for Cursor and VS Code, plus setup steps for claude.ai and ChatGPT. There's more about what our server can do in Give your agent a recipe database.

Want to go further? Build a recipe chatbot with Claude and MCP shows how to wire an MCP server into your own app. Next up in this series, we'll build an MCP server from scratch in TypeScript. Then we'll cover how to design tools that a model actually picks correctly.