MCP Basics

By the Syncfusion DevTutorials team · Last updated October 20, 2026

What the Model Context Protocol is, why it was made, the open spec and its 2026-07-28 version, the standard shape of every setup, and the three things a server can offer: tools, resources and prompts.

Imagine you buy a new lamp. You do not need the lamp maker to build a special socket for your house. You just plug it in. Every lamp fits every wall socket because both use the same plug standard.

AI apps used to work without a standard plug. Every time a chat app needed to read orders, open tickets, or search a wiki, someone wrote special code for just that app and that system. If you had ten apps and ten systems, you could end up with a hundred pieces of special code.

The Model Context Protocol or MCP is the standard plug for AI apps. An app that uses MCP can connect to any system that uses MCP.

The main idea: MCP is one shared way for AI apps to find and use tools and data. Build the connection once, and every MCP app can use it.

A Real-World Example

Think about a USB-C port.

• Your laptop has one kind of port.
• A keyboard, a screen, and a phone charger all use the same port.
• The laptop asks the device what it is and what it can do, then uses it.

MCP works the same way. An AI app asks a server what it can do. The server answers with a list: "I have a tool to look up orders, a returns policy you can read, and a ready-made reply prompt." The app can then use them, without any special code for that server.

In simple words: MCP is like a USB-C port for AI apps. Systems plug in, say what they offer, and the app uses them.

What You Will Learn

In this lesson, you will learn:

1. What MCP is and why it was made.
2. Why it is an open protocol, and what its rules (specification) cover.
3. The standard shape of every MCP setup.
4. The three things a server can offer: tools, resources, and prompts.
5. Where MCP is useful, and where it is not.

MCP Definition

What MCP Is

MCP is a protocol. A protocol is a set of rules that two programs agree on, so they can talk without knowing each other's code. HTTP is the protocol your browser uses to talk to websites. MCP is the protocol an AI app uses to talk to tools and data.

The two sides in MCP are:

• A client, which lives inside the AI app. It asks for things.
• A server, which sits in front of a system, like an order database. It answers.

The client and server send each other small messages written in JSON. JSON is a simple text format for data, made of names and values in curly braces.

Why MCP Was Made

A language model by itself only knows its training data and what is in its context. It cannot check today's orders or open a ticket. To do that, an app must connect it to real systems.

Before MCP, each app built each connection by hand. This is called the N × M problem: N apps times M systems gives N × M connections to build and maintain. With MCP, each app builds one client and each system builds one server. That is N + M pieces.

N × M versus N + M

// 4 AI apps need to reach 5 company systems.
const apps = ["Chat app", "Code editor", "Support bot", "Phone assistant"];
const systems = ["Orders", "Tickets", "Wiki", "Calendar", "Files"];

// Without a shared protocol: every app needs its own link to every system.
const custom = apps.length * systems.length;

// With MCP: each app gets one MCP client, each system gets one MCP server.
const withMcp = apps.length + systems.length;

console.log("Custom links to build:", custom);
console.log("MCP pieces to build:  ", withMcp);
console.log(
  "Add one more app:     ",
  (apps.length + 1) * systems.length,
  "vs",
  apps.length + 1 + systems.length,
);

Expected output:

Custom links to build: 20
MCP pieces to build:   9
Add one more app:      25 vs 10

Adding one app costs five new custom links, but only one new MCP client. The difference gets bigger as you add more.

An Open Protocol

MCP is open. Anyone can read the rules and build a client or a server for free. No company has to give you permission.

• Anthropic first released MCP in November 2024.
• It is now an open project that many companies help run.
• The rules are written down in a document called the specification, or spec.

Each version of the spec is named by its date. This course follows the current version, 2026-07-28. You may sometimes find older servers that still use 2025-11-25. We point out the differences when they matter.

Spec Overview

The spec has a few main parts. You do not need to learn them all now. Just know they exist:

Standard Architecture

One Shape for Every Setup

Every MCP setup has the same shape:

• The host is the AI app the user opens, like a chat app or a code editor.
• Inside the host, there is one client for each server it connects to.
• Each server gives access to one system, like orders or a wiki.

You will study each role closely in the next lesson.

What a Message Looks Like

MCP messages follow JSON-RPC 2.0. That is a small, older standard for "call a method on another program". Each request has a method name, an id, and params.

Here is the real request a client sends to ask a server for its tools. In the 2026-07-28 spec, every request carries the protocol version and who is asking, inside a field called _meta.

A real MCP request

// The real message a client sends to ask a server for its tools.
// It is JSON-RPC 2.0: a method name, an id, and params.
const request = {
  jsonrpc: "2.0",
  id: 1,
  method: "tools/list",
  params: {
    _meta: {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { name: "mcp-lab-host", version: "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {},
    },
  },
};

console.log("method:", request.method);
console.log(
  "protocol version:",
  request.params._meta["io.modelcontextprotocol/protocolVersion"],
);
console.log("sent by:", request.params._meta["io.modelcontextprotocol/clientInfo"].name);

Expected output:

method: tools/list
protocol version: 2026-07-28
sent by: mcp-lab-host

The server answers with the same id, so the client knows which question the answer belongs to:

A real MCP reply

// The server's reply, trimmed. Same id as the request, so the client can match them.
const reply = {
  jsonrpc: "2.0",
  id: 1,
  result: {
    tools: [
      {
        name: "lookup_order",
        description: "Get the status and delivery date of one order.",
        inputSchema: {
          type: "object",
          properties: { order_id: { type: "string" } },
          required: ["order_id"],
        },
        annotations: { readOnlyHint: true },
      },
      {
        name: "create_ticket",
        description: "Open a ticket for a human agent.",
        inputSchema: {
          type: "object",
          properties: {
            summary: { type: "string" },
            priority: { type: "string", enum: ["low", "high"] },
          },
          required: ["summary", "priority"],
        },
        annotations: { readOnlyHint: false },
      },
    ],
    resultType: "complete",
  },
};

console.log("reply to request id:", reply.id);
console.log("resultType:", reply.result.resultType);
for (const t of reply.result.tools) {
  console.log("-", t.name, "needs", t.inputSchema.required.join(" + "));
}

Expected output:

reply to request id: 1
resultType: complete
- lookup_order needs order_id
- create_ticket needs summary + priority

Each tool comes with an input schema. A schema is a description of what the arguments must look like. Here, lookup_order needs one text value called order_id.

Press the button and open the Inspector tab. You will see the client's first message, server/discover, and the server's answer. Click any message to see its real JSON.

Uniform Model-System Integration

Because every server answers the same methods, the host does not need special code for each server. It can:

1. Ask any server for its list of tools.
2. Show those tools to the model.
3. Call whichever tool the model picks, with tools/call.

That is what uniform integration means: one way to connect, for every system.

Capability Scope

Tools

A tool is an action the model can ask for, like "look up order A-1001" or "open a ticket". Tools are model-controlled: the model decides when a tool would help. Some tools only read data. Others change things.

Resources

A resource is data the app can read, like a file, a policy page, or a database schema. Each resource has an address called a URI, such as kb://returns-policy. Resources are application-driven: the app decides which ones to put into the model's context. Reading a resource should never change anything.

Prompts

A prompt is a ready-made message template the server offers, like "reply to a customer". Prompts are user-controlled: the user picks one, often from a menu or a slash command, and fills in its arguments.

Who decides when each one is used

// The three things an MCP server can offer, and who decides when each is used.
const offers = [
  {
    kind: "Tools",
    example: "lookup_order",
    decidedBy: "the model",
    sideEffects: "maybe",
  },
  {
    kind: "Resources",
    example: "kb://returns-policy",
    decidedBy: "the app",
    sideEffects: "no",
  },
  {
    kind: "Prompts",
    example: "reply_to_customer",
    decidedBy: "the user",
    sideEffects: "no",
  },
];

for (const o of offers) {
  console.log(
    `${o.kind.padEnd(9)} | ${o.example.padEnd(19)} | chosen by ${o.decidedBy.padEnd(9)} | side effects: ${o.sideEffects}`,
  );
}

Expected output:

Tools     | lookup_order        | chosen by the model | side effects: maybe
Resources | kb://returns-policy | chosen by the app   | side effects: no
Prompts   | reply_to_customer   | chosen by the user  | side effects: no

Permissions and Auditing

MCP lets a server offer powerful actions. So the spec sets out safety principles:

• User consent: the user must understand and agree to what happens to their data, and to actions that change things.
• Tool safety: a tool can run real code. The host should ask the user before calling a tool that changes something.
• Data privacy: the host must not send user data to a server without the user agreeing.

The protocol carries the information. The host enforces these rules: it shows approval prompts, keeps a log of every call, and can block tools. A good server helps by marking tools, for example with readOnlyHint: true for a tool that only reads.

Where MCP Fits

MCP is a good fit when:

• An AI model needs to use tools or data from other systems.
• Several AI apps should share the same tools.
• You want to add or change tools without changing the app's code.

MCP is not the answer when:

• No AI model is involved. A script that copies data each night should just call the system's normal API.
• One app makes one fixed call that will never change. A direct API call can be simpler.
• You need to move huge amounts of data fast. MCP is made for an AI app's requests, not bulk data transfer.

Is MCP a good fit?

// A quick rule of thumb: is MCP a good fit for this job?
function mcpFits(job) {
  if (!job.aiUsesIt) {
    return "no: no AI model is involved, use a normal API";
  }
  if (job.oneAppOneSystem && !job.willGrow) {
    return "maybe: a direct call may be simpler";
  }
  return "yes: an AI app needs tools or data it can discover";
}

const jobs = [
  {
    name: "Nightly report script",
    aiUsesIt: false,
    oneAppOneSystem: true,
    willGrow: false,
  },
  {
    name: "One chatbot, one fixed lookup",
    aiUsesIt: true,
    oneAppOneSystem: true,
    willGrow: false,
  },
  {
    name: "Assistant for orders and tickets",
    aiUsesIt: true,
    oneAppOneSystem: false,
    willGrow: true,
  },
];

for (const j of jobs) {
  console.log(j.name.padEnd(33), "->", mcpFits(j));
}

Expected output:

Nightly report script             -> no: no AI model is involved, use a normal API
One chatbot, one fixed lookup     -> maybe: a direct call may be simpler
Assistant for orders and tickets  -> yes: an AI app needs tools or data it can discover

MCP does not replace APIs. An MCP server usually calls the system's normal API behind the scenes. MCP is the standard front door that AI apps use.

Common mistakes

• Thinking MCP makes the model smarter. MCP only brings tools and data to the app. The model still needs good context and good instructions.
• Thinking the server runs the model. The model lives in the host. The server never sees the model. It only gets requests from the client.
• Using MCP where no AI is involved. If a normal program calls a normal API, MCP adds a layer for no gain.
• Following an old tutorial. Steps like initialize, ping, and session ids belong to older versions. The current spec is 2026-07-28.
• Mixing up the three offers. A resource is for reading. An action that changes data belongs in a tool, so the host can ask for approval.

Exercises

Each exercise ends with a value on the last line. Press Check to compare it with the expected answer.

What to Remember

• MCP is an open protocol: one shared way for AI apps to find and use tools and data.
• It turns the N × M problem into N + M: one client per app, one server per system.
• Messages are JSON-RPC 2.0. In the current spec, 2026-07-28, each request carries its version in _meta.
• A server can offer tools (the model decides), resources (the app decides), and prompts (the user decides).
• The host enforces consent, approvals, and audit logs. Server hints help but are not promises.
• Use MCP when an AI app needs tools or data. Use a plain API when no AI is involved.

Next: MCP Mental Model, the five roles in every setup and the job each one does.