Connect an AI agent to your data: MCP and API keys

So far the agent has only touched files you made in an empty folder. Useful, and also the smallest version of what it can do. The shift happens when it can reach the tools you already run on: your analytics, your CMS, your email platform, your Slack.

Once it can, the work changes shape. You ask for last week’s GA4 numbers and get the written recap, not a screenshot to retype. Point it at your CMS and every thin meta description gets fixed in one pass. Feed it your product analytics and it tells you where people fall out of the funnel, with the figures. A whole client blog runs on connections like these, one person, the assembly handed off.

This lesson opens that door, and it is the one where a little care earns its keep, because you are handing over keys.

There are two ways to connect a tool, and you will use both. Start with the tidier one.

MCP, the ready-made connectors

For the popular tools there is a clean option worth trying first. MCP is a fast-growing standard for pre-built connectors. Someone has already done the wiring. Instead of raw API calls, you install a connector for Slack, your analytics, or your CMS, and authorize it once. The move is the same as connecting any app to another.

After that the agent gets a tidy, named set of actions to work with, the ones the connector chose to expose. Less fiddly to set up, and usually better behaved, because the connector puts sensible limits on what is possible. The one catch is coverage. A connector has to exist, and today that means the bigger platforms. Slack, Notion, Figma, HubSpot, and Stripe all ship official ones, and the list grows most weeks.

API keys for the long tail

Most of your stack has no connector yet. The list grows most weeks, and still, the tool you need is often not on it. Inside a chat app, that is where the road ends: no connector, no connection. Working from an editor, a missing connector changes very little, because the agent can write the calls itself.

Most tools you touch have an API, a way for other software to talk to them. That API lets you create a key that stands in for your login. You hand the agent that key and it can call the tool directly. No connector required, which is why this is the one you reach for most.

In practice you mix the two. A connector for the big platforms that have one, and a key for the long tail, which is most of what you actually use. Between them you can wire up almost anything in your stack. A key is just a long string of characters, and it needs one safe place to sit.

The .env file, where your keys live

Your keys go in one file, called .env, in your project folder. You point the agent at a key by its name, like GA4_KEY, so the secret itself never has to go into the chat. The value stays in the file, and the tool reads it only when it makes a call.

.env file

A plain text file named .env that holds your secret keys, one per line, like GA4_KEY=abc123. You and the agent refer to a key by its name, not its value, so the secret lives in the file, not in your chat. The file stays on your machine, and the version-control lesson keeps it out of anything you share.

Two habits protect what is in that file, and they matter more than anything else in this lesson. Never paste an actual key into the chat, a prompt, or a script, even to give it to the agent. It only needs the name, and anything you type into a chat can be saved or seen. And never let the file into your project history, which is exactly what that one line in the git lesson sets up. The key is your login, so treat it like your password.

You do not make the file by hand either. Have the agent scaffold it:

Set up secret storage for this folder. Ask me which tools I am connecting, then create a .env file with a named placeholder line for each, like GA4_KEY=paste-here, and make sure .env is listed in .gitignore. Do not ask me for the values. I will paste them into the file myself in the editor. From now on refer to my keys by name only, and never read, print, or edit the .env file unless I ask you to.

Check the agent added .env to .gitignore, which the prompt above asks for and the version-control lesson explains. Then open .env in your editor and paste the real values in yourself. This is the one place typing a secret is right, because the value goes straight into a file on your machine instead of through the chat. From that point the agent works with the names. When a call runs, the tool reads the value from the file directly. The prompt above tells the agent never to open that file unless you ask. As long as you never have it, or a command, print or read the file, the value stays out of the chat.

What you can actually plug in

Here is what that looks like in practice. These are the tools I connect to in my own work, and the kind of thing the agent does once it is wired in. None of it is exotic, and most marketers already pay for half this list.

And to show how far the same idea reaches, a handful you may already use, and what their APIs make possible:

The point is the range. If a tool matters to your week, it almost certainly has a way in, through a connector or a key.

Least access, always

Here is the habit that keeps you out of trouble, and it is simple. Give the agent the least access that does the job.

When you create a key or authorize a connector, most tools let you choose what it can do. If the agent only needs to read your analytics to pull last week’s numbers, create a read-only key. It cannot change or delete anything, so even a session that goes sideways cannot do damage. Only grant write access when the task genuinely writes, like posting a message or updating a page. Even then, scope it as narrowly as the tool allows.

I keep a read-only connection to one of our databases for exactly this reason. The agent can look at everything and touch nothing. That is the posture you want by default.

The safety net underneath

Two things protect you here, and they work together. In its default mode the agent asks before it does anything it cannot undo, which you saw in setup, so a write or a delete stops for your approval. And the key you gave it can only do what you scoped it to.

The prompts are the moment-to-moment check. The read-only key is the guarantee that holds even if you approve too quickly. Lean on the second one. It is the one that does not depend on you paying attention.