What Is an MCP Server? Meaning, Examples and How It Works

Ask an AI assistant to summarize last quarter's sales and it will politely tell you it cannot see your spreadsheet. The model is clever, but it sits in a box with no doors. An MCP server is the door. It is a small program that exposes one capability, such as reading files, querying a database or generating an image, to any AI app that speaks the Model Context Protocol. Write the server once, and every compatible app can use it without custom glue code.

This article explains what an MCP server is, how a request travels from your chat window to the tool and back, which servers people run today, where the security risks sit, and how to build a working one in about twenty lines of TypeScript.

What an MCP Server Actually Means

MCP stands for Model Context Protocol, an open standard that Anthropic released in November 2024. A protocol is just an agreed way of talking. An MCP server is any program that follows those rules on the supplying side: it announces what it can do, waits for requests, and returns results in a predictable format. Products from Anthropic, OpenAI, Google and Microsoft now support MCP, and thousands of community servers exist for everything from Git repositories to calendars.

The word server confuses people. An MCP server does not have to live in a data center. Most run on your own laptop as a background process that starts when your AI app launches. Others run remotely behind a web address, much like any website.

MCP in Plain English

Picture an old telephone exchange. Callers do not need to know how every house is wired. They tell the operator who they want, and the operator plugs the right cord into the right socket. MCP plays the operator's role between an AI app and the outside world. The app says I need to read this file or I need to run this query, and the protocol routes the request to a server that knows how.

💡 Quick definition: An MCP server is a program that lists the tools, data and prompt templates it offers, and lets an AI app call them through one standard message format.

The USB-C Comparison

The most popular analogy is USB-C. Before it, every device had its own plug and every laptop needed a drawer of adapters. Before MCP, every AI app needed a custom connector for every service: one for Slack in this assistant, another for Slack in that one. Count the combinations. Five apps and ten services meant fifty separate integrations. With MCP, each app implements the client side once and each service implements a server once, so fifteen pieces of work replace fifty.

How an MCP Server Works

Three roles show up in every MCP setup, and keeping them straight removes most of the confusion.

Host, Client and Server

The host creates one client per server. Connect five servers and your app runs five clients, each with a private line to its own server. Messages travel as JSON-RPC 2.0, a lightweight request and response format that has been around for years. Nothing exotic.

What Happens in One Request

Here is the path of a single question, which invoices are overdue?, through a host connected to an accounting server:

1. Handshake. When the host starts, the client sends initialize. Client and server agree on a protocol version and trade their capabilities.
2. Tool listing. The client calls tools/list. The server replies with every tool name, a plain description and a JSON Schema for the inputs.
3. Decision. The model reads your question plus those tool descriptions and decides that list_overdue_invoices is the right move.
4. Approval. Most hosts show the call and ask you before running anything that changes data.
5. Execution. The client sends tools/call with the tool name and arguments. The server does the real work, such as running a SQL query.
6. Answer. The server returns the result, the model reads it and writes a normal reply.

The call in step 5 is a small JSON message:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "list_overdue_invoices",
    "arguments": { "days_overdue": 30 }
  }
}

Copy Prompt

The model never touches your database. It only produces a request. The server holds the credentials and does the work, which is exactly why servers are the right place to enforce limits.

Local Versus Remote Transports

A transport is the pipe that carries those JSON messages. MCP defines two standard ones.

Servers that use stdio talk through standard input and output, so there is no network port to attack. Streamable HTTP servers can serve many users at once, which is why software companies publish them. Older tutorials mention an HTTP+SSE transport. The current specification replaced it with Streamable HTTP.

What a Server Can Offer

Tools, Resources and Prompts

An MCP server exposes up to three kinds of building blocks.

Tools get almost all the attention because they let an AI do things. Resources are quieter but just as useful: they feed context into the conversation without a tool call. Prompts work like slash commands that a server ships with itself.

Why Descriptions Matter So Much

The model picks tools by reading their names and descriptions, nothing else. A tool called run with the description "does stuff" will be misused or ignored. A tool called search_invoices with the description "Find invoices by customer name, status or date range. Returns up to 20 results." gets chosen at the right moment.

Good tool design comes down to four habits:

• Name with a verb and a noun, such as create_ticket or list_branches.
• State what comes back, not only what the tool does.
• Keep inputs small and typed, and use fixed choices where possible.
• Return errors as readable text, so the model can fix its input and retry.

💡 Tip: If an assistant keeps picking the wrong tool, rewrite the description before touching any code. In practice that fixes most mix-ups.

Real MCP Server Examples

The fastest way to grasp the idea is to look at what people actually run.

File System Servers

The reference file system server lets an assistant read, search and edit files inside folders you choose. Point it at a project directory and ask for every TODO comment grouped by file. The server can only reach the folders you listed, so the assistant works inside a fence you drew.

Database and Search Servers

Database servers expose a query tool, and sometimes the table layout as a resource. Ask which three customers spent the most in September, and the model writes the SQL, the server runs it and rows come back. Many teams set these up as read-only on purpose. Search and web servers work the same way, giving the model fresh pages instead of stale training data. Other popular servers connect GitHub, Slack, Google Drive, Notion, Postgres and browser automation.

Image and Video Generation Servers

Generation is where MCP turns visual. An image server exposes a generate_image tool. The assistant writes the prompt, the server calls a model, and a file URL lands back in the chat. Video works the same way, with one difference: clips take longer, so the server starts a job and the assistant checks on it until it finishes.

PicassoIA runs on this pattern. Its developer API lives at https://api.picassoia.com/v1 and uses a Bearer token that starts with pia_sk_. Requests follow the Replicate style: create a prediction, poll it until it ends, then fetch the result. Each account can run 5 predictions at once. The same four models are reachable through the API and through the PicassoIA MCP connector:

• PicassoIA Image for text to image
• PicassoIA Image Editor Pro for editing existing pictures
• PicassoIA Video for video from text or an image
• Seedance 2.5 Lite for video with audio

MCP connections are managed from the MCP page of your PicassoIA account, and the pricing page lists what each plan includes. If you would rather make clips by hand than through an assistant, models such as Seedance 2.0 and Veo 3.1 are a click away.

A Publishing Server in Practice

One more example, closer to home. A blog publishing server can expose four tools: generate an image, check whether a URL slug is free, list the available AI models and save the finished article to a database. An assistant given a topic calls them in order, retries any image that fails and stores the result. Nobody wrote an "article bot." The model simply had the right tools and a clear job.

MCP Versus a Regular API

An MCP server usually wraps an ordinary API, so why add a layer? Because the reader is different. A REST API is written for developers who read documentation. An MCP server is written for a model that has to read the documentation at runtime.

MCP does not replace function calling. The host translates the server's tool list into the function calling format the model already knows. MCP only standardizes where that list comes from.

💡 Rule of thumb: Building one app with a handful of private functions? Plain function calling is enough. Want the same capability in several assistants, or want teammates to plug it in? Write an MCP server.

Security Questions Worth Asking

An MCP server is code that an AI can trigger, often with real credentials behind it. Treat it like any other software that touches your accounts. Five questions catch most problems:

• Who wrote it? A server from an unknown author runs with your permissions. Read the source or stick to trusted publishers.
• What can it reach? Give each server the narrowest access: one folder, a read-only database role, a token limited to one repository.
• Who approves actions? Keep confirmation prompts on for anything that writes, sends or deletes.
• Where do secrets live? Put tokens in environment variables, never in tool descriptions or prompts.
• What does it read? Web pages, emails and documents can hide instructions aimed at the model, a problem called prompt injection. A server that fetches outside text deserves tight permissions.

⚠️ Watch out: A tool description is text the model trusts. A malicious server can hide instructions inside it. Only connect servers you would be comfortable installing as software.

How to Build Your Own

Building a server takes less work than most people expect. Official SDKs exist for TypeScript, Python, Java, C# and several other languages. The same three steps apply in all of them: create a server, register a tool, connect a transport.

A Minimal Server in TypeScript

This example registers one tool that counts words and serves it over stdio. Save it as an ES module.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "word-counter", version: "1.0.0" });

server.registerTool(
  "count_words",
  {
    description: "Count the words in a piece of text. Returns a single number.",
    inputSchema: { text: z.string() },
  },
  async ({ text }) => ({
    content: [
      { type: "text", text: String(text.trim().split(/\s+/).filter(Boolean).length) },
    ],
  })
);

await server.connect(new StdioServerTransport());

Copy Prompt

Build it, then add one entry to your host's config file: a name, the command node and the path to the built file. Restart the host and count_words appears in its tool list. Ask "how many words are in this paragraph?" and the assistant calls your code instead of guessing.

Testing With the Inspector

Before blaming the model, test the server alone. The official MCP Inspector (npx @modelcontextprotocol/inspector node build/index.js) opens a browser page where you can list tools, fill in arguments and read the raw responses. If it works there, the problem lives in the host config or in the tool description.

Try It With PicassoIA

MCP servers mostly speak text, yet plenty of workflows end with a picture or a clip. A good order of work is to draft the idea with a language model, then turn it into visuals. PicassoIA Image handles photographs, PicassoIA Image Editor Pro fixes and reshapes them, and PicassoIA Video animates the result.

How to Use Claude Sonnet 5

A model that handles tool use and code makes a solid partner for building the server above. Here is the quick path with Claude Sonnet 5 on PicassoIA:

1. Open the model page. Go to the Claude Sonnet 5 page on PicassoIA.
2. Write the Prompt. It is the only required field. Try: "Write an MCP server in TypeScript with one tool that returns today's date."
3. Pick the Effort level. The default, low, is fast and cheap. Switch to high or max when a task spans several files or hides a tricky bug.
4. Set a System Prompt. For example: "You are a senior TypeScript developer. Return runnable code and one sentence of explanation." Reuse it across the whole project.
5. Adjust Max Tokens. The default is 8192, enough for a full server file. Attach an Image, such as a screenshot of an error, if it helps. Max Image Resolution defaults to 0.5 megapixels to keep requests quick.
6. Generate and test. Run the code through the Inspector before trusting it.

Other language models are worth a side-by-side test: GPT 5.6 Terra for production-ready text, Gemini 3.5 Flash for quick answers, and Kimi K2.6 for agent-style tasks.

Make Your First Image Today

You now know what an MCP server does, how a request moves through it and where the risks hide. The fastest way to feel the idea is to use a tool that returns something you can see. Open Picasso IA, describe one scene in a single sentence, and generate it. Then run the same prompt on a second model and compare the results. Small, swappable tools are the habit MCP rewards, and a first image takes less than a minute. Try it with Picasso IA now and see where your prompt leads.