How I connected AI to my tools

There was a moment when I stopped copying and pasting things into the chat and started letting the assistant look for them itself. It was a huge step forward, and also the day I had to think seriously about what I'd let it touch. This is about the MCPs I use, how they're installed and, above all, how I limit them.

"Connect artificial intelligence to all your apps in 30 seconds". I've seen it on so many thumbnails that I know the presenter's surprised face by heart.

My real figures: the first working MCP took me a whole afternoon, about four hours, and the setup I have today is the result of about four months of adding, removing and putting things back. The first attempt was a small disaster: I installed a local file connector, configured it pointing at a folder that didn't exist because of a mistake in the path, and spent an hour convinced the problem was Claude's. It was mine, a misplaced slash.

But I don't want to stop at the anecdote. The serious subject of this article is something else: connecting is quick, especially now; deciding what the machine can touch is not.

MCP stands for Model Context Protocol, an open standard introduced by Anthropic, the company behind Claude, at the end of 2024, and now supported by many other assistants and programs. It lets a language model use tools and data that live outside the chat: your email, your files, the browser or a database.

The comparison that works best is the universal plug. Before, each assistant needed a custom-built connection for each tool; with MCP it's enough for both to speak the same language. The piece that acts as the bridge is called an "MCP server": a small program that connects to a specific tool and tells the model what it can do with it.

The typical confusion: MCP isn't an artificial intelligence, nor a program you download and you're done. It's the common language. Each tool needs its own connector.

I work mostly with Claude, and MCPs are part of my day. These are the ones I currently use:

Email. I use it to search threads and prepare drafts. Real task: "find me this client's emails about the June quote and summarise what we agreed". It's remote, I connect with my account.

Files. Access to the client projects folder. Real task: compare two versions of a contract and tell me what changed. It's local, it runs on my machine.

Browser. So it can check a website, fill in a test form or verify that a page loads properly after a change. Local.

Database. Read-only on the database of one of my own projects. Real task: "how many orders came in last week and from which provinces?", without me having to write the query. Local, against a copy.

Calendar. Remote. To ask what I have next week and find free slots, nothing more.

I use it with other models too: locally, with one of the models running on my home servers, I connect the file MCP so it can work with documents I don't want leaving my network. That's the advantage of the standard: the same connector works with different assistants.

There are two routes, depending on where you work.

From the Claude app, in the connector settings. That's how I installed the calendar one: you go into settings, find the connector, click connect, sign in with your account and accept the permissions it asks for. Three minutes, and here the 30-second promise does get close to reality. From Claude Code, Claude's tool that works in the terminal (that black window where you type commands). That's how I installed the database one: with a command along the lines of claude mcp add, giving the name and how the server starts, then checking it appears in the list of active connectors. The practical difference between them: remote ones are an internet service you connect to with your account, and local ones are a program running on your machine. Local ones reach your files without going through anyone else; remote ones depend on what the provider lets you do.

And in ChatGPT? If what you want is to connect ChatGPT to your Gmail, it's done from settings, in the apps section (they used to be called connectors): you choose Gmail, sign in with Google and accept the permissions. Whether it shows up depends on your plan and your country (checked in September 2026; worth reviewing before taking anything for granted).

Now the serious part.

There's a huge difference between reading and acting. Searching for an email isn't the same as sending it, let alone deleting it. Reading a file isn't the same as overwriting it. When you connect something, it's worth looking at exactly what it asks for. In my case: the email one asked to read, create drafts and send, and I took away the send permission, so it stays at reading and preparing drafts; the file one, to read and write; the browser one, to control a window; the database and calendar ones, only to read.

Then there's the problem of third-party data. In my work email it isn't just me: there are clients, suppliers, conversations with people who haven't given permission for an assistant to read them. Before connecting your work email, you have to ask yourself that question.

A clarification that reassures a lot of people: the assistant doesn't watch your inbox or act on its own. It works when you ask it to, unless you set up an automation so it does things by itself.

And the most treacherous risk isn't technical, it's habit. When the assistant proposes an action and asks for confirmation, at first you read everything. By the twentieth time, you click "accept" without looking. That's where things happen.

My concrete measures are these: a separate email account for testing; read-only whenever the task allows it; mandatory confirmation before sending or deleting anything; the file MCP restricted to one working folder and never the whole disk; the database, always against a copy; and before installing an MCP, I check who publishes it, how many people use it and, if it's open source, what it does.

That last one is the most important. Installing an MCP of unknown origin is handing your house keys to a stranger who seemed nice at the door. They might be good people. Or not.

And if you change your mind, permissions can be removed: for remote connectors, by disconnecting them in the assistant's settings and revoking access in the service's account (in Google, for example, from the security section); for local ones, by removing them from the configuration.

In May 2026 I asked the assistant to tidy up a project folder: "group the files by type and remove the duplicates". It took two different versions of a quote with almost identical names as duplicates and proposed deleting the most recent one. I was busy with something else and clicked accept. I noticed the next day, when I went to send it.

There was no harm because the folder was synced and I could recover the earlier version in five minutes. But the scare changed two things for me: now the file MCP can't delete, only move things to a "review" folder, and I do clean-up tasks with a list beforehand that I read before approving.

I'm telling you this because a near miss teaches more than ten successes.

If you're new to this, I'd start with these three: the file one restricted to a single folder, because you immediately see what it brings; the calendar one in read-only mode, because it can't break anything; and the browser one, to understand how an assistant acts outside the chat.

The ones I wouldn't install without thinking: work email with send permission, any MCP that gives access to payments or banking, and any of unknown origin that asks for access to the whole disk.

My advice is the one I would have liked to hear myself: one at a time. Install it, understand what it does and what it can touch, use it for a week, and then the next one. It'll take you longer than 30 seconds, but you'll sleep better.