How AI agents reach your data: MCP and API keys

So far the agent has worked on what sits inside your project folder: the page you built, the practice company you fetched. Useful, and also the closed 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. Those live outside the folder, behind logins.

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.

A little care earns its keep here, because you are handing over keys. There are two ways to connect a tool, and you will use both.

MCP, the ready-made connectors

MCP is a fast-growing standard for pre-built connectors: someone has already done the wiring. 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.

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.

What you can actually plug in

Nearly all of these are tools I connect to in my own work, and most marketers already pay for half the list. The tag on each cell is the road in, as things stand today. MCP means an official connector exists; API means the agent writes the calls itself.

The .env file, where your keys live

A key is just a long string of characters, and it needs one safe place to sit. That place is a file called .env in your project folder.

.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 matter more than anything else in this lesson. Never paste an actual key into the chat, a prompt, or a script, and never have the agent read or print the file either. It only needs the name; anything that goes through the 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.

There is nothing to put in a .env yet: Tempo’s folder is static files on purpose, so nothing in this course needs a login. Your own stack gets wired in during the Build your marketing brain tutorial. The agent scaffolds the file there, the moment the first real key exists. When that day comes, you paste the value in yourself, in the editor, straight into the file: the one place typing a secret is right.

Least access, always

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.

Assignment: plan Tempo’s live wiring

Tempo ships a file mapping every export to the live tool it stands in for. Turn it into the wiring plan you would run if Tempo were real; the plan stays in the chat, no files made.

Read tempo/connectors.md. For each source, tell me how you would wire it live: an official connector if one exists or an API key if not, and the least access it needs for the work this folder does. Then show me the .env this setup would need, named placeholders only, and do not create any files.

Done when every source has a road in, an access level, and a placeholder name, all in the chat.

The safety net underneath

In its default mode the agent asks before it does anything it cannot undo, 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, and it does not depend on you paying attention.