[Teach Me, AI Sensei] What is MCP? Things to Consider Before Giving Tools to AI

Recently, I have been hearing the term MCP quite often in the AI community.

MCP support.
MCP server.
Tool integration via MCP.
Agentification via MCP.

I feel like I've been seeing these kinds of discussions quite a lot lately.

The articles and posts I come across seem, if anything, to be mostly positive introductions to the possibilities of MCP.

AI connecting to various tools.
Advancing agentification.
Being able to reference external data.
Allowing AI to use business tools.

It certainly seems convenient.

However, personally, there are some points that concern me.

The fact that AI connects to external tools also means that the information the AI can see and the scope of what it can operate are expanding.

While it becomes more convenient, isn't it dangerous if handled incorrectly?

Instead of just viewing MCP as a convenient connection standard,

"What to show"
"What to allow it to operate"
"Where humans should intervene"

I think we need to consider these aspects as well.

Including such questions, I asked AI Sensei about it.

Since it's a bit hard to understand with just words, let's first look at the big picture with an image diagram.

MCP is a mechanism for connecting AI to external tools and data.

However, it's not the case that just by installing MCP, everything can be used safely.
You need to think carefully and separately about what to connect and how much to allow it to use.

Now, let's organize this step by step.

First, in a nutshell,

MCP is a common standard for AI to connect to external tools and data.

To put it more bluntly,

It is something like that.

For example, when humans work, they go to look at various things.

Check emails.
Check the calendar.
Look at files.
Look at the internal Wiki.
Look at tickets.
Look at the database.
Search.
Update something if necessary.

We want to make AI do the same thing.

However, it is difficult if the connection method is different for each tool.

Therefore,

is the idea that emerged.

That is MCP.

However, MCP is not an all-purpose safety device.

I want to emphasize this first.

MCP is convenient.

It makes it easier for AI to see external data and use tools.
It is also compatible with agentification.
It makes it easier to connect AI from simple chat to actual work environments.

However, just because you introduced MCP does not mean that detailed permission control and safety design will be solved automatically.

MCP is, after all, a "mechanism for connecting."

What to show.
What to let it operate.
How far to let it execute.
Whether to allow deletion.
Whether to allow external transmission.
Whether to let it touch the production environment.
Where to insert human approval.

MCP itself does not automatically do all of these designs.

The system side of the connection destination.
The MCP server side.
The host side that runs the AI.
And the human side that introduces it.

Therefore, it is necessary to design it properly.

In short,

I think it is dangerous to take this lightly.

How is it different from API integration?

You might think, 'If it's just connecting to external tools, can't we do that with API integration?'

You certainly can.

However, API integration is basically handled individually for each app and each tool.

Connect this API to this AI app.
Connect to another AI app using a different method.
Every time a tool is added, you have to think about how to connect it.

If you do this, it becomes more difficult as the number of combinations increases.

MCP aims to create a common connection point for that.

Instead of connecting individually for each AI, you connect to external tools and data using a common method.

Thinking of it that way, MCP can be called a 'common connection standard for AI.'

The explanation that it's like USB-C

In explanations of MCP, the analogy of USB-C is often used.

With USB-C, you can connect various peripherals to your computer.

Monitors.
Keyboards.
External storage.
Chargers.

Instead of creating completely separate, dedicated ports for each device, you connect them using a common port.

MCP has a similar image to that.

The AI app side supports MCP.
The tool side is also prepared as an MCP server.
Then, the AI can easily use that tool.

However, caution is required here as well.

Just because there is a USB-C port doesn't mean it's safe to plug anything into it.

What are you connecting?
What can the connected device do?
How much access does it have?

Those are things that need to be considered separately.

MCP is the same.

"Connecting" and "using safely" are two different things.

What is an MCP server?

When researching MCP, the term MCP server also comes up.

This is also a bit confusing.

Roughly speaking, an MCP server is

is what it is.

For example, suppose there is an MCP server for file searching.

That server provides the AI with:

"You can search this folder."
"You can read this file."
"You can return results in this format."

It provides these functions.

If it's for a database,

"You can search this DB."
"You can reference this table."
"You can execute this query."

It provides functions like these.

An AI app connects to an MCP server as an MCP client and uses those functions.

That is the general idea.

However, what is important here as well is

.

Will you show all files?
Will you show only some folders?
Will you make the DB read-only?
Will you allow updates as well?
Will you even allow deletions?

If you are careless about this, MCP becomes dangerous in an instant.

An MCP server is a convenient gateway, but since it is a gateway, you need to carefully decide what to expose to the outside.

What is the benefit?

The benefit of MCP is that AI is no longer an isolated chat.

Ordinary chat AIs basically answer within that conversation.

But if you really want to use it for work, you want the AI to look at external information.

Look at the latest documents.
Look at past meeting minutes.
Look at ticket status.
Look at the calendar.
Search for files.
In some cases, create something.

With MCP, it becomes easier to handle such external tool integration in a common way.

In other words, MCP is also compatible with agentification.

For an agent to proceed with work, it needs tools.

Tools to investigate.
Tools to read.
Tools to write.
Tools to update.
Tools to notify.

It is easy to understand if you see MCP as a common standard for handing those tools to an AI agent.

But convenience and danger come as a set

I think this is the most important point.

MCP is convenient.
But convenience and danger come as a set.

AI can read files.
Can search the DB.
Can update tickets.
Can post to Slack.
Can write emails.
Can operate external services.

At this point, it is no longer just a simple chat.

The AI will be reaching into your work environment.

Therefore, the important thing when introducing MCP is not to end it at "it's connected and convenient."

Rather, because it connects, there is more to think about.

What information should be shown?
What operations should be permitted?
Is it read-only?
Should writing also be permitted?
Should external transmissions require human approval?
Will logs be kept?
Who can stop it?
Is it set up so that it cannot touch the production environment?

I think it is quite dangerous to introduce MCP without designing these aspects.

MCP is a "pipeline." Therefore, be careful about what you let flow through it.

In my own words, MCP is very much like a "pipeline."

A pipeline that connects AI to external tools.

When you have a pipeline, you can let various things flow through it.
That is convenient.

However, the pipeline itself does not automatically judge:

"This is information that is okay to let flow."
"This is information that must not flow."
"This person is allowed to see up to this point."
"This operation is dangerous, so I will stop it."

It does not judge all of these things for you.

What to let flow.
How far to let it flow.
Who to let it flow to.
How to prevent backflow.
How to ensure it does not leak outside.

That requires design outside of the pipeline.

MCP is the same.

MCP is useful as a "connection mechanism."
However, detailed business permissions and safety barriers need to be properly restricted on the original system or the MCP server side.

I think it is better to be strongly aware of this.

Starting with read-only is safe.

If you are going to use MCP, I think it is safe to start with read-only operations.

For example,

Reading documents.
Searching for files.
Checking the calendar.
Viewing ticket status.
Searching the internal wiki.

These are the kinds of things.

In other words, allowing the AI to "see."

In the next stage,

Creating drafts.
Creating update proposals.
Creating issue candidates.
Creating reply drafts.
Creating PR proposals.

Up to this point, it is still easy for humans to verify.

On the other hand, from the beginning,

Sending emails.
Posting to Slack.
Updating tickets.
Updating the DB.
Deleting files.
Operating the production environment.

You should be quite cautious about allowing things like this.

If you are going to give tools to an AI, start with safe tools first.

Read-only.
Up to drafts only.
With human approval.
With logs.
No deletions.
No production operations.

I think starting from this level is realistic.

Where do you restrict things to make them read-only?

What I am curious about here is,

"Can I automatically control things like read-only access if I use MCP?"

This point.

In my understanding, this is also quite important.

MCP itself does not handle all the detailed business permission controls for you.

If you want to make it read-only, basically,

This kind of design is necessary.

For example, if it is an MCP server that handles files, what you allow should be limited to:

• Viewing file lists

• Reading files

• Searching for files

or something similar.

Conversely,

• Writing files

• Deleting files

• Moving files

• Changing folder structures

functions like these should not be exposed by the MCP server in the first place.

If handling a database,

• Allowing only SELECT

• Showing only read-only views

• Connecting with a read-only user

should be the approach.

Conversely,

• INSERT

• UPDATE

• DELETE

• DROP

• Permission changes

• Administrative operations

should be restricted.

For S3, provide only read-only IAM permissions. For GitHub, set it to read-only access. For internal wikis, show only the scope that is viewable.

In other words, to make it read-only, you need to combine and narrow down:

• permissions on the connected system side

• functions exposed by the MCP server

• approval settings and usage restrictions on the AI host side

to restrict access.

If you are careless about this,

it could happen that 'you intended it to be read-only, but in reality, update-type tools were also callable by the AI'.

Therefore, when introducing MCP,

you need to verify:

What you are showing the AI. What you are letting the AI operate. Which tools the MCP server is exposing. Whether the permissions of the connection destination are truly read-only.

You must check these.

MCP is a convenient connection interface.

However, to use it safely, you must properly restrict the permissions beyond the connection point.

I think this is a very important point when implementing it.

Relationship with Agentification

This also connects to the previous discussion on agentification.

Agentification was about having AI handle part of the work.

However, to proceed with work, you need materials and tools.

View meeting logs.
View documents.
View emails.
View calendars.
View tickets.
Create drafts if necessary.

MCP serves as the connection point to those materials and tools.

In other words,

is what it is.

However, the more tools you give it, the more important permission management and safety guardrails become.

Giving tools to AI.
But, it doesn't mean you should give it everything.

If you get this wrong, it could become a gateway to accidents rather than agentification.

Today's Understanding

MCP is a common standard for AI to connect to external tools and data.

It is a mechanism to connect AI from an isolated chat to a work environment.

However, MCP is not an all-purpose safety device.

MCP is a 'connecting mechanism.'
That is precisely why you need to carefully design what to connect and how much access to allow.

The information AI can see increases.
The tools AI can use increase.
The operations AI can perform increase.

That is convenient.

However, convenience and danger go hand in hand.

Start with read-only access.
Limit to the necessary scope.
Require human approval for writing or sending.
Keep logs.
Do not allow deletions.
Do not allow access to production environments.

MCP is a standard for giving tools to AI.
But it is humans who decide which tools to provide.

And the extent to which those tools can be used must be restricted by the MCP server and the underlying system, not left to MCP itself.

That is my understanding for today.