What is MCP?
Let's make it simple.

Okay, what does MCP actually mean?

You ask an AI assistant to help with an article. It gives you a draft. Lovely. Then you want it to find the approved brief in your files, check the deadline in your tracker, and put the finished draft somewhere useful.

Now the question changes. How does the assistant reach any of that?

MCP stands for Model Context Protocol. It is an open standard that lets AI applications communicate with external tools and data sources. It gives compatible software a shared way to offer information and actions to an AI app. Source: the official MCP introduction.

If you are thinking, “That still sounds a little technical,” stay with me.

Imagine the assistant is helping you at a desk. The brief is in one cabinet, the tracker is in another, and your publishing system is somewhere else. You can carry each piece over yourself. Or the application can use an authorised connection to ask for a particular piece of information or a particular action.

MCP describes how that conversation between the software works. You still need the connection, the right capability, and permission to use it.

I find this much easier to understand through a small piece of work. So this guide follows a fictional content desk: a few documents, a tracker, and a place to save drafts. You can try the examples below without connecting an account.

Three names, one understandable connection

You will keep seeing host, client, and server. Here is what those words are doing.

The host: the AI application you use

The host is the application that coordinates the work. It manages the model, the conversation, and its MCP clients. Think of the app window you are working in.

The client: the MCP-speaking part inside it

An MCP client is the component the host uses to communicate with an MCP server. You usually do not open it as a separate app. It is part of the connection happening behind the interface.

The server: the program offering capabilities

An MCP server exposes particular capabilities to the client. It might run on your computer or remotely. “Server” describes its role; it does not necessarily mean a physical machine you need to buy. Source: MCP architecture.

In our fictional setup, the AI app is the host. Its client talks to a Content Desk MCP server. That server offers operations for looking up documents, reading a task record, and creating an unpublished draft.

The content desk still holds the records. The model works with the information the application makes available. Keeping those roles separate helps you ask a useful question when something fails: which part could not do its job?

Tools, resources, and prompts: what can a server offer?

The three core server features are tools, resources, and prompts. A server does not have to offer all three, and your app may present them differently. Official server concepts explain the distinction.

Tools do a defined operation

A tool is a callable operation, such as searching records or creating a draft. Tools can read information as well as make changes. The model can request a tool, while the application and server control whether it may run.

In our example, search_documents finds a brief's record. create_draft creates a new draft. Both are tools. “Tool” does not automatically mean “changes something.”

Resources supply context

A resource provides information the application can load as context, such as a document's contents. It is read-only in this part of the protocol. Imagine the approved brief made available for the assistant to read.

Prompts provide reusable starting instructions

An MCP prompt is a reusable message template a user can select. An illustrative “Review this brief” prompt could ask for gaps, assumptions, and open questions. It is different from the ordinary word “prompt,” which also means the message you type.

The usual control distinction is model-led tools, application-led resources, and user-selected prompts. For a beginner, the practical question is simpler: am I asking for information, asking for an operation, or choosing a prepared instruction? The official SDK's first-steps guide explains those roles.

These are protocol categories. They do not determine the quality of your brief or whether the draft is ready for a client. You still need to describe the work clearly.

Try it: follow a request through the connection

Choose an example, then move through the steps. You will see the request, the available tools, the proposed arguments, the access decision, and the result.

Try the document search first. Then switch to creating a draft. At the access step, turn access off or decline the draft to see how that changes the outcome.

If you are listening: the first example looks up an approved brief's record. The second reads a deadline from a sample tracker. The third proposes creating an unpublished draft. A permitted request returns a sample result; a denied request stops without a result or a change. The interactive version lets you explore each branch.

This is a teaching simulation with fixed sample records. It does not run an AI model, operate a real MCP server, or connect to your accounts. The approval screen illustrates one application's policy; MCP does not prescribe this exact screen or require a fresh approval dialog for every tool call.

What just happened in the brief example?

Let's slow it down.

You asked for an outcome

“Find the approved brief for the MCP guide.” You described what you wanted. You did not have to write the technical request yourself.

The app had a way to discover a tool

MCP defines tools/list for discovering tool definitions and tools/call for invoking a selected tool. A tool definition describes its purpose and expected inputs. Source: the tools specification.

In the simulation, search_documents is a sensible choice because the task is to locate a document record. Creating a draft would be a different operation, even though both relate to content.

The proposed call had specific inputs

The example passes a query and an Approved status. Those inputs narrow the lookup. A vague instruction becomes a particular operation the application can inspect.

The result came from the sample system

The returned record contains an ID, a title, and a status. The illustrative answer can say it found that record. It cannot honestly summarise the whole brief because the search result did not include the brief's contents.

That is a useful habit when you use connected tools yourself: ask what was actually retrieved. Finding a file, opening it, understanding it, and changing it are different parts of the work.

You checked the outcome

If the result is the wrong brief, the next step is to correct the search or clarify which document you meant. A connection can return the wrong match. The answer still needs your judgement.

Three everyday ways to picture it

These are illustrative workflows. The actual tools depend on the server, application support, account, and permissions you have.

Example 1: find the latest approved brand brief

Imagine a small team with several versions of a brief. You ask the assistant to find the one marked Approved and show its title, date, and location. A document-search capability could help locate the record. You check the version before using it.

I would make the request narrow: the project name, the status, and what I want returned. If two files match, I would want the assistant to show both and ask which one I mean.

Example 2: understand what needs attention this week

Imagine a content tracker with an owner, deadline, and status for each article. A permitted read operation could retrieve the relevant rows. The assistant could then group the items that need review and explain which dates it used.

I would ask it to keep missing dates visible. An empty deadline should remain an open question instead of becoming an invented due date in a polished summary.

Example 3: create a draft after you approve the brief

Imagine a publishing system with a create-draft operation. After checking the destination and proposed content, you authorise that particular draft. The result should give you a record or link you can open and inspect.

I would keep creating a draft and publishing a page as separate decisions. The example is useful because “put this somewhere for me to review” is a much smaller action than making it public.

Notice the pattern across all three: a clear request, a relevant capability, an access decision, and an outcome you can check. That is the level I would understand first, before worrying about configuration files.

MCP, APIs, and instructions are doing different jobs

An API is an interface to a service

An MCP server can call an existing service's API underneath its tools. MCP standardises the AI-app-facing exchange; the service still needs its own implementation and access rules. The tools specification includes API interaction among tool uses.

So I would not begin by asking whether the work needs “an API or MCP.” First ask what the service supports and how your AI application can reach the particular operation. Sometimes both are part of the same route.

Instructions explain what you want done

A reusable review instruction might say, “Check whether each claim has a source.” A connection supplies the ability to retrieve an accessible source or update a supported record. You can have detailed instructions and still lack access to the file.

In our content example, the workflow says how to review the draft. The tool connection offers a way to retrieve it. I would keep those questions separate when deciding what the setup needs.

Organisation helps you keep the work together

Putting your briefs and decisions in a sensible place is another part of the process. If that is the piece you need first, start with my guide to organising work in ChatGPT. Then come back to the connection when you know which outside information or action the task requires.

Reading and changing deserve separate decisions

Reading a brief and changing a publishing record have different consequences. I would begin with the smallest access that supports the task. The official security guidance recommends limiting permissions to what is needed. Source: MCP security best practices.

For our example, I would first test whether the correct brief can be found. I would add draft creation only after the lookup is useful and the destination is clear.

Before authorising a change, I would want to understand the account, the destination, the proposed content, and whether the action creates a draft or publishes it. That makes the decision concrete.

Approval behaviour depends on the host and server implementation. MCP's tools guidance recommends human oversight, but it does not guarantee every app uses the same approval pattern. Check the controls in the application you actually use. Source: tool interaction guidance.

A sentence in your prompt can express your preference. It does not replace technical access controls. For work that should only read, choose read access where the integration supports it.

Also check the source of a server before installing or connecting it. The security documentation describes risks from compromised local servers. Local software can have access on the machine where it runs; “local” alone is not a safety guarantee. More in the official security guide.

How I would try a first real connection

You do not need to build a server to understand the idea. If your AI application already supports an appropriate integration, start with its documented setup. If it does not, this guide's demo still gives you a way to learn the concepts.

1. Choose one small task

Use a sample document you are allowed to share. Give it a distinctive title and a short paragraph whose contents you know. Your first test can be finding that document and reporting one detail from it.

2. Check the actual support

Look at the documentation for both the application and the server or integration. Check supported devices, account requirements, available operations, and the provider. A service having an API does not mean your current app has an MCP connection ready to use.

3. Follow that provider's setup

A remote server runs elsewhere; a local server runs on your machine. Their setup and authentication can differ. Use the instructions for the particular host and server rather than copying an unrelated tutorial's configuration. The architecture overview explains local and remote connections.

I would avoid collecting extra integrations at this stage. Connect the one needed for the test, verify the account, and review the requested access.

4. Ask for a result you can check

Then open the document yourself. Did it find the right one? Is the quoted sentence actually there? If the connection cannot retrieve the document, that is something to resolve before adding a bigger task.

5. Try an awkward case

Search for a title that does not exist. A useful response should say it did not find a match, rather than produce a plausible document summary. Try two similar titles too, and check how it handles the ambiguity.

Once that small test behaves sensibly, you have a clearer basis for deciding whether to keep the connection and what to try next.

When something does not work, check which step failed

“The AI did not do it” is a difficult problem to diagnose. I would break the task into smaller questions.

Can the app reach the connection?

Check the application's connection status and the server's documented requirements. For a local setup, check whether the required software is running. For a remote setup, follow the provider's connection instructions.

Is the required operation available?

If the integration can search documents but cannot create drafts, changing the wording of your request will not supply a missing operation. Check the actual tool list or supported-action documentation.

Is it using the right account and input?

Check the account, the document identifier, and any search filters. A wrong status filter can hide the record you wanted. Missing access can also prevent the request from succeeding.

Did the tool succeed, and did the answer reflect the result?

Look for an error or a returned record in the activity details, where your app exposes them. “Draft created” should be supported by the result and a draft you can inspect. A fluent answer on its own is not enough evidence.

This is also why I like a very small first task. When you know the expected document and expected answer, you have something specific to compare.

The questions beginners usually have

Sources, and your next useful step

Technical references checked November 2, 2026. The content-desk names, tool names, records, and approval flow in the demo are illustrative. These official sources support the protocol explanations:

• What is MCP?
• Architecture overview
• Understanding MCP servers
• Tools specification
• SDK first steps: tools, resources, and prompts
• Security best practices

If you want to turn a connection into a useful process, start with the work you want to keep together. If your briefs and drafts need a clearer home, try setting up a Project.

For now, pick one small lookup you wish you did not have to do manually. Describe the input and the result you want. That gives the connection a job.