Understanding MCP: How AI Connects to the Tools We Already Use

Exploring Model Context Protocol (MCP), how it works, and how platforms like ChatGPT and Claude use integrations to interact with external systems.

Generative AI · Applied AI · Software Engineering

---

Imagine asking an AI assistant:

"Check my calendar for tomorrow, find any conflicting meetings, and create a task in my project management app."

Sounds pretty straightforward, right?

We already have AI models capable of understanding what we're asking. They can analyze schedules, identify conflicts, and suggest what we should do next.

But there's a problem.

How does the AI actually access our calendar?

How does it know which tasks already exist?

And more importantly, how can it create a task in another application?

At first, I thought this was simply a matter of integrating an AI model with a few APIs.

And technically, that's possible.

But as I started learning more about Applied AI Engineering, I came across something called Model Context Protocol, or MCP.

What interested me wasn't just what MCP could do. It was the architectural problem it was trying to solve.

AI Can Think, but It Needs a Way to Interact

Let's imagine hiring a really smart personal assistant.

This assistant can understand complex instructions, organize information, and make reasonable decisions.

However, on their first day, they don't have access to anything.

They can't open the company's calendar, read internal documents, or update project tasks.

They're intelligent, but disconnected.

An AI model faces a similar limitation.

A Large Language Model (LLM) can generate responses based on its training and the context provided to it. But that doesn't automatically give it access to external applications.

For example, if we ask:

"How many pending tasks do I have in Todoist?"

The model cannot reliably answer unless our application provides that information.

Similarly, if we ask:

"Create a meeting for Monday at 10 AM."

Understanding the instruction doesn't mean the model can actually create that meeting.

This brings us to an important distinction:

Understanding an action and executing an action are two different capabilities.

As software developers, we're already familiar with this separation.

A frontend application can understand what a user wants to do, but it still needs to communicate with a backend API to perform the operation.

AI-powered applications face a similar challenge.

So, What Exactly Is MCP?

MCP stands for Model Context Protocol.

It's an open protocol that standardizes how AI applications connect to external tools, systems, and data sources.

Think of it as a common communication interface between AI applications and the services they want to interact with.

Here's an analogy.

Imagine we're building a laptop.

Without standardized interfaces, every external device might require a completely different connection mechanism.

A mouse needs one connector, a keyboard needs another, and an external drive needs something else.

Standards like USB make this easier by defining a common way for compatible devices to communicate.

MCP follows a similar idea, but for AI applications.

Instead of building a completely different integration mechanism for every AI platform, developers can expose capabilities through a standardized protocol.

An AI application that supports MCP can then discover and interact with those capabilities.

However, there's an important detail.

MCP doesn't replace the APIs behind those services.

A Google Calendar integration still needs a way to communicate with Google Calendar. A database integration still needs database access.

MCP standardizes how AI applications interact with integrations, not how every underlying service works internally.

And that's what makes it interesting from a software engineering perspective.

The Problem MCP Is Trying to Solve

Let's say we're building an AI assistant that integrates with three services:

1. Google Calendar
2. Todoist
3. GitHub

Without MCP, we could develop custom integrations for each service.

Our application would communicate with their APIs, process responses, and expose relevant functions to the AI model.

That's manageable.

But now imagine we want the same integrations to work across multiple AI applications.

Perhaps our users want to use ChatGPT, Claude, or another MCP-compatible assistant.

Different AI platforms may have different integration mechanisms and tool-calling interfaces.

We could end up repeatedly adapting the same services for different environments.

This is where MCP becomes useful.

Instead of treating every AI platform and external service as a completely unique integration, MCP establishes a shared communication contract.

The AI application handles the conversation and coordination.

The MCP server exposes capabilities that the application can discover and use.

The underlying service still performs the actual work.

This separation makes integrations more reusable, although authentication, permissions, hosting, and platform compatibility still need to be handled.

How Does MCP Actually Work?

To understand the architecture, we need to know three important components.

1. MCP Host

The host is the AI application where the user interacts with the system.

For example, an MCP-compatible AI assistant.

It's responsible for managing the overall experience, coordinating available connections, and deciding how external capabilities fit into a conversation.

2. MCP Client

The client is the component that maintains communication with an MCP server.

Usually, the AI application creates a client connection for each MCP server it connects to.

The client handles protocol-level communication, such as discovering available tools and sending requests.

3. MCP Server

The server exposes capabilities that an AI application can use.

For example, a project management MCP server might expose functions such as:

• get_tasks
• create_task
• update_task_status

These are illustrative tool names, not a universal MCP requirement.

The MCP server can communicate with an external API, database, or another system to execute the requested operation.

Putting Everything Together

Imagine we ask:

"Create a Todoist task to review my portfolio tomorrow."

A simplified interaction would look like this:

1. The user sends the request to an AI application.
2. The AI application has access to the capabilities advertised by its connected MCP servers.
3. The model determines that a task-creation tool could help fulfill the request.
4. The host coordinates the tool call through its MCP client.
5. The MCP server receives the request and communicates with Todoist.
6. The result returns to the AI application.
7. The assistant reports whether the task was successfully created.

Notice something important?

The LLM isn't directly executing a Todoist API request.

It's participating in a workflow coordinated by the host application, which communicates with the external system through the MCP connection.

This distinction matters because the model's decision to request an action isn't the same as the system successfully completing that action.

MCP Isn't Just About Calling Tools

Initially, I associated MCP mainly with giving AI the ability to execute external functions.

But MCP defines several important capabilities.

Three fundamental ones are tools, resources, and prompts.

Tools: Performing Operations

Tools expose functions that an AI application can invoke.

For example:

• Creating a calendar event.
• Querying an order database.
• Updating a project task.
• Checking a deployment status.

Tools may read information or modify external state, depending on their implementation and permissions.

Resources: Providing Information

Resources expose information that an AI application can read.

For example:

• Application configuration.
• Internal documentation.
• Database schema information.
• Project-related data.

Think of resources as information made available through a standardized interface.

Prompts: Reusable Interaction Templates

Prompts allow MCP servers to expose predefined prompt templates.

For example, an engineering tool could provide a structured template for reviewing a deployment or investigating an incident.

The idea is to make reusable workflows easier to discover and invoke.

These capabilities serve different purposes.

Tools provide operations, resources provide information, and prompts provide structured interaction templates.

A single MCP server doesn't necessarily need to expose all three.

So, What Are Plugins in ChatGPT?

Now that we understand MCP, let's connect it to something more familiar.

ChatGPT has a plugin system that allows users to extend its capabilities.

At first glance, plugins might look like integrations with external services.

But the distinction is a little more interesting.

A ChatGPT plugin can package multiple capabilities into a reusable workflow.

Depending on the plugin, those capabilities may include:

• Skills: Reusable instructions that guide the assistant through a particular workflow.
• Apps: Integrations that let ChatGPT access external services or perform supported actions.
• Interactive experiences: Interfaces provided by supported apps.

For example, imagine creating a plugin called Engineering Weekly Review.

Its purpose is to help a developer review their work every Friday.

The plugin could contain a skill that defines how to structure the review.

It could also use connected apps to retrieve completed tasks from a project management system and inspect relevant GitHub activity.

The skill describes how to perform the workflow.

The apps provide access to the necessary systems.

And ChatGPT coordinates the process.

This means a plugin isn't necessarily an MCP server.

A plugin is more like a package of capabilities, while MCP is a protocol that some of those capabilities may use.

Some plugins can work entirely through instructions without accessing external services.

Others may rely on MCP-backed apps.

That's an important distinction because the terms describe different layers of the system.

What About Connectors in Claude?

Claude also supports integrations with external services through something called Connectors.

Connectors allow Claude to access information and perform supported actions in connected applications.

For example, a connector might help Claude retrieve project information, inspect documents, or interact with another service.

Claude supports both available integrations and custom connectors built using MCP.

A developer can expose a remote MCP server and configure Claude to communicate with it.

For local workflows, supported Claude desktop environments can also use local integrations.

So how is this different from ChatGPT Plugins?

The concepts overlap, but their product-level roles aren't exactly the same.

Claude Connectors primarily describe connections to external services.

ChatGPT Plugins can package reusable instructions and application capabilities into a broader workflow.

Both can use MCP, but MCP itself is independent of either platform.

An easy way to think about it is:

MCP is the communication standard. Connectors and apps provide integrations. Plugins can organize capabilities into reusable workflows.

How Is MCP Different from RAG?

This question came to mind because I previously explored Retrieval-Augmented Generation, or RAG.

Both MCP and RAG can help AI applications work with external information.

But they solve different problems.

RAG is an approach for retrieving relevant information and providing it as context before generating an answer.

MCP is a protocol for exposing external capabilities to AI applications.

For example, imagine we're building an internal employee assistant.

An employee asks:

"What's the company's current leave policy?"

A RAG system might search internal documents and retrieve the relevant policy.

The assistant then uses that information to answer the question.

Now imagine the employee asks:

"How many annual leave days do I have left?"

This may require accessing the employee's actual leave balance through an HR system.

An MCP server could expose a tool that retrieves that information.

What if the employee asks:

"Submit a leave request for next Monday."

Now the assistant may need to execute an operation through the HR system, potentially after user confirmation.

An MCP tool could provide that capability.

The difference becomes clearer:

RAG	MCP
An information-retrieval approach	A communication protocol
Focuses on retrieving relevant context	Standardizes access to external capabilities
Often supports question answering	Can support reading data and performing actions
Can use search indexes or databases	Uses MCP clients and servers

And here's the interesting part.

RAG and MCP can work together.

An MCP server could expose a search tool backed by a RAG retrieval system.

The AI application uses MCP to invoke the search capability, while the retrieval system handles finding relevant information.

They're not competing technologies.

They operate at different architectural layers.

Does MCP Make AI Applications Autonomous?

Not automatically.

This is probably one of the most important things to understand.

Giving an AI access to external tools doesn't guarantee that it will use them correctly.

Imagine an assistant connected to a database.

It might understand that it needs to update a customer record.

But what happens if it chooses the wrong customer?

What if it misunderstands an instruction?

What if the retrieved information contains malicious instructions?

Or what if the tool has permission to modify more information than the user intended?

These are real engineering concerns.

MCP standardizes communication, but it doesn't automatically solve authorization, security, business validation, or reliability.

As developers, we still need to consider:

• Authentication and authorization: Who is allowed to access which data or perform which actions?
• Least privilege: Does the integration have more permissions than it actually needs?
• Input validation: Are tool parameters validated before executing operations?
• Confirmation: Should sensitive or destructive actions require explicit approval?
• Observability: Can we trace which tools were called and whether they succeeded?
• Prompt injection: Could untrusted external content influence the assistant to perform unintended actions?

In traditional backend development, we don't trust user input simply because it arrived through a valid HTTP request.

The same principle applies here.

An AI-generated tool call still needs to respect the system's security boundaries.

When Should We Actually Use MCP?

As a full-stack web developer, I find MCP interesting because much of the underlying work feels familiar.

We already build APIs, define contracts, integrate services, manage authentication, and handle permissions.

MCP brings those engineering concepts into a standardized interface for AI applications.

But that doesn't mean every AI-powered application needs it.

For example, if we're building a simple application that sends a prompt to an LLM and displays the response, MCP might add unnecessary complexity.

Even if our application uses a few internal functions, ordinary function calling may already be enough.

MCP becomes more interesting when we need reusable integrations that can work across compatible AI applications.

It can also be useful when we're exposing an existing system's capabilities to AI assistants without rebuilding the integration for every host.

However, introducing MCP also means managing additional components, connections, permissions, and operational concerns.

So instead of asking:

"How can I add MCP to my application?"

I think a better question is:

"Do I actually need a standardized integration boundary between my AI application and external systems?"

If the answer is yes, MCP might be a good architectural choice.

If not, a simpler integration may be more practical.

Final Thoughts

Learning about MCP changed the way I think about AI-powered applications.

Initially, I focused mostly on the models themselves.

Which model is smarter?

Which model has better reasoning capabilities?

Which model produces more accurate answers?

Those questions still matter.

But as I explore Applied AI Engineering, I'm realizing that a useful AI application involves much more than the model.

A model might understand what needs to happen, but the surrounding system determines what information it can access, which actions it can perform, and how safely those actions are executed.

RAG helped me understand how external knowledge can improve AI-generated answers.

MCP introduced another perspective: how external systems can expose capabilities through a common protocol.

And products like ChatGPT Plugins and Claude Connectors show how those ideas can become practical integrations.

For me, the biggest takeaway is simple:

Building AI applications isn't only about making models smarter. It's also about designing the systems that allow those models to interact with the world reliably.

And honestly, that's where Applied AI Engineering starts to feel a lot like software engineering.

---

References & Further Reading

• Model Context Protocol — Official Documentation
• MCP — Architecture Overview
• OpenAI — Plugins in ChatGPT
• OpenAI — Connected Apps in ChatGPT
• Anthropic — Use Connectors to Extend Claude's Capabilities

This article is part of my journey exploring Generative and Applied AI from the perspective of a full-stack software developer.