What Is MCP (Model Context Protocol), and Why Does It Matter?

What is MCP in plain English?#

MCP is a shared set of rules that lets an AI application, such as a chat assistant or a code editor, plug into other systems without a custom connection for each one. The official documentation compares it to a USB-C port: one standard way to connect many different devices, so that a connector built once works in many places.

Without a shared standard, every AI application needs its own connector for every system it talks to. MCP aims to replace that with one protocol that both sides understand. The documentation lists examples such as an assistant reading your calendar and notes, an enterprise chatbot querying several databases, and a coding tool turning a design file into a web app.

The documentation describes benefits for three groups:

• Developers: less time and complexity when building, or integrating with, an AI application or agent.
• AI applications and agents: access to an ecosystem of data sources, tools and apps.
• End users: more capable applications that can reach user data and take actions on the user's behalf when necessary.

MCP is an open protocol, and the documentation lists chat assistants and development tools from several companies that support it.

How does MCP work?#

MCP uses a client-server design. The AI application is the host. For each server it connects to, the host creates an MCP client that keeps a dedicated connection. Each server is a program that provides context and capabilities. The client asks a server what it offers, then calls those features when the application needs them.

The architecture overview describes three participants:

Two layers#

MCP has a data layer and a transport layer. The data layer uses JSON-RPC 2.0 messages and defines discovery (a client can ask which protocol versions and capabilities a server supports), the server features and notifications, such as a server telling clients that its list of tools has changed. The transport layer carries those messages. A local server on the same machine typically uses standard input and output (stdio). A remote server uses Streamable HTTP, which supports standard authentication such as bearer tokens and API keys, and MCP recommends OAuth for obtaining tokens.

Three things a server can offer#

The specification calls these server features. Each has a different party in control:

A client discovers features with list requests (for example tools/list) and runs a tool with tools/call. Each tool describes its inputs with a schema, so the application knows what information a call needs. This is how tool calling works through MCP.

Why does MCP matter for AI applications?#

MCP matters because it turns many one-off integrations into one shared pattern. A team can build a server once and use it from any host that supports the protocol, and a host can reach many servers without new connector code for each. For organisations, that means more choice, but also more connections that need checking.

For builders, the practical effects are:

• Reuse. The same server can work with different AI applications that support MCP.
• Discovery. An application can list what a server offers at run time, so tools can be added or changed without rebuilding the application.
• Separation of concerns. The architecture overview says MCP focuses only on the protocol for context exchange. It does not dictate how AI applications use a large language model (LLM) or manage the context they receive.

That last point clarifies what MCP is not. An AI agent is the application that plans and decides which tools to use. MCP is one standard way to give that agent its tools and data. Some workflow automation platforms now offer MCP features too; our comparison of n8n, Zapier and Make, linked below, describes them.

What are the security and safety rules in the specification?#

The specification says MCP enables powerful capabilities through data access and code execution, so it sets out key principles: user consent and control, data privacy and tool safety. Hosts must get explicit consent before sharing user data with servers or invoking any tool. MCP cannot enforce these principles itself, so implementers must build them in.

The main points from the specification and its security best practices:

• Users stay in control. Users must consent to and understand data access and operations, and keep control over what is shared and what actions are taken.
• Tools are code. Tools represent arbitrary code execution. Descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server.
• Data stays where agreed. Hosts must not transmit resource data elsewhere without user consent.
• Local servers need care. A local server can have direct access to the machine it runs on. The security guidance says a client offering one-click setup must show the exact command it will run and require explicit approval, and should run servers with minimal privileges, for example in a sandbox.

The server concepts page lists controls an application can offer, such as approval dialogs for individual tool calls, permission settings for pre-approving safe operations and activity logs of every tool call. These are forms of human in the loop oversight, and they only help if someone reads what they are approving.

What does MCP look like in a Singapore workplace?#

Consider an illustrative scenario: a small accounting practice in Tanjong Pagar wants its AI assistant to read non-confidential policy templates from a shared folder and to create follow-up tasks in its task tracker. MCP could connect the assistant to both, provided the practice controls what each server can read and do.

A sensible approach would be to:

1. Start read-only. Connect a server that exposes the templates folder as resources only, and check that the assistant answers questions from those files.
2. Add one tool. Add a "create task" tool, keep approval on for every call, and read each proposed task before approving it.
3. Check the source. Use servers from a known publisher, and ask whoever handles IT to review the exact command or address before anything is installed.
4. Use invented data. Test with made-up client names. Client details can be personal data under the PDPA, so decide where that data may flow before real records are involved.
5. Test what could go wrong. Ask for something the assistant should refuse, such as deleting tasks, and confirm it cannot. Our guide to testing AI-generated outputs, linked below, has a routine you can follow.

The value is in a controlled connection, not in connecting everything at once.

What are the common mistakes with MCP?#

The common mistakes are treating a connection as safe because it uses a standard, granting broad access too early and approving tool calls without reading them. MCP standardises how systems talk. It does not decide whether a particular server is trustworthy or whether a particular action is a good idea. Those decisions stay with you.

• Installing servers from unknown sources. A local server runs code on your machine with the client's privileges.
• Starting with write access. Begin with resources and read-only tools, then add actions one at a time.
• Approving on autopilot. Approval dialogs are only useful if someone checks what the call will do.
• Trusting tool descriptions blindly. The specification says descriptions should be treated as untrusted unless they come from a trusted server.
• Using real personal data in a prototype. Use invented records until the setup has been reviewed and approved.
• Skipping logs. Keep a record of tool calls so you can see what happened and undo mistakes.

What to learn next#

Next, learn how AI applications find and use your own documents, and how automation platforms connect apps in fixed workflows. Then practise building something small and testing it properly. The links below follow a sensible order for builders, from concepts to hands-on practice, and connect to the wider learning pathway.

If you would rather build and test with guidance, GenAI Builder Sprint is a 2-day classroom course where adults plan, build, test and launch a simple AI app. No previous AI or programming experience is needed, although formal entry requirements apply.

Sources#

1. What is the Model Context Protocol (MCP)?, Model Context Protocol, accessed 8 November 2026
2. Architecture overview, Model Context Protocol, accessed 8 November 2026
3. Understanding MCP servers, Model Context Protocol, accessed 8 November 2026
4. Specification, Model Context Protocol, accessed 8 November 2026
5. Security Best Practices, Model Context Protocol, accessed 8 November 2026

Frequently asked questions#

What is MCP?+

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems such as local files, databases, tools and workflows. Its own documentation compares it to a USB-C port: one standard way to connect many different things.

What are MCP hosts, clients and servers?+

The host is the AI application, such as a chat assistant or a code editor. It creates one MCP client for each server it connects to, and each client keeps a dedicated connection. The server is the program that provides context and capabilities, and it can run on your own machine or remotely.

What can an MCP server offer?+

Three building blocks. Tools are functions the model can call to take actions. Resources are data the application can read for context. Prompts are reusable instruction templates that a user chooses to run.

Is MCP the same as an AI agent?+

No. MCP is the protocol for exchanging context and capabilities. Its documentation says it does not dictate how AI applications use language models or manage the context they receive. An agent is the application that decides which tools to use, and MCP is one way to give it those tools.

Is MCP safe to use at work?+

It can be, with care. The specification asks hosts to get explicit user consent before sharing user data with a server or invoking any tool, and it treats tools as arbitrary code execution. MCP cannot enforce these principles itself, so the application and your own approval process have to.

What are common mistakes with MCP?+

Connecting servers from unknown sources, granting write access before read-only access has been tested, approving tool calls without reading them, using real personal data in early tests and assuming the protocol makes a connection safe.