Instagram marketing with Claude and other MCP clients

What MCP actually is

MCP, the Model Context Protocol, is a shared format between an AI client and an outside service. The service publishes tools, each with a name, a description and an input schema. The client reads those descriptions and picks the tool that fits. Claude, Codex, Cursor and other clients speak the same format, so one endpoint serves several.

Two consequences follow. The description is the interface: a tool that says what it does, what it needs and what it refuses gets used correctly. And the server decides what exists. A client cannot invent a capability.

MCP does not make an agent careful or honest. It makes it connected. Everything after that is a question of access.

Draw the boundary before you write a prompt

Marketing work touches three things at once: your brand, your money and a record you will rely on months later. A weak caption costs an afternoon. A wrong number in a report costs trust in every decision after it.

So the order is: decide what may be read, what may be written and who says yes. Then choose a client. Many do it the other way round and meet the boundary after a mistake.

A one-page agreement with three lists is enough.

• Read: brand context, priority, tests, measurements with their age, saved research.
• Write: log a test, save a find, record a number you named.
• Never: publish, change settings, invent a value, delete history.

What an agent should be able to read

The useful read set is smaller than most people assume: brand context with the claims you can defend, the current priority, existing tests and their measurements, saved research with your note, your own Reels and their numbers.

Age is not a detail. A view count without the age of the measurement cannot be compared with anything. Two numbers taken at different ages do not say which post did better.

Read access is data access. Whatever sits in the workspace can end up in a chat, a log or a screenshot. Store what you would paste into a chat and leave the rest out.

What an agent should be allowed to write

Good writes share three properties. They add to the record instead of rewriting it, they can be traced to a person and a moment, and they can be checked later.

In practice: log a test with one changed variable, save a research find, record a number you read out loud, record a business outcome, attach a finished version to a test. These are entries, not edits.

Bad writes are easy to list: publishing, changing account settings, deleting measurements, filling a gap with an estimate, sending anything to anyone.

What a real confirmation looks like

A confirmation is not a friendly question. Before the write, the agent names the tool, the content and the target. You say yes to that specific action. Only then does the write happen.

Per action, never per session. A blanket yes at the start turns every later confirmation into decoration, and you will not remember what you agreed to.

Refusal is normal. A tool that answers with a confirmation error is working as intended. Treat it as a stop sign. An agent that looks for a way around it has shown you something.

One limit: confirmation is product behaviour, not a security boundary. The key carries the rights either way.

Keys: one purpose, one owner, one way out

One key per client or per person, named for where it lives: laptop Claude, studio Cursor. If two people share a workspace, two keys. Otherwise the record cannot say who did what.

Keep the key in the client's MCP configuration and nowhere else. Not in a repository, a note or a chat with a third party. If you must paste it somewhere unusual to make it work, stop.

A revoked key stops working on the next call. What it did before stays in the record. You can cut access without losing the history.

For today: list every key, revoke the ones you cannot place, set a reminder for the next device change.

A weekly loop that survives real life

Pick one pattern from public posts and write down what you saw. Change exactly one variable: hook, length, topic, format or posting time. Two changes at once teach you nothing about either.

Note the views at 24 hours, 72 hours and 168 hours, always at the same age. The comparison is the median of at least three earlier tests at the same age, on the same channel, from the same data source and with the same trial status. With fewer earlier tests, or a missing value, the honest answer is: not enough data yet.

Example: your usual Reel has a median of about 1,000 views at 24 hours and a new one has about 1,300 at the same age. That is 30 percent more, so the verdict is share. At 400 it would be minus 60 percent, so drop. Anything between minus 20 and plus 20 percent is repeat, not a win.

Then decide per measurement point, at 24 hours already: share, repeat or drop. Write it down in one line. Confidence is low with three to seven earlier tests and medium from eight. An estimate per variant needs at least eight comparable tests, three per variant.

Where a workspace like marketingapp.io fits

marketingapp.io is a workspace for Instagram Reels tests with an MCP endpoint. The agent reads what the app shows: business and priority with the next step, pulse and measured effect per variant, brand context, tests with their measurements, saved research, your own Reels with their numbers.

Writes are the entries above: log a test, mark a planned test as published, save a find, record a measurement you named, record a business outcome, submit a locally edited version. Each write needs your explicit confirmation for that action and a briefing token from a fresh read, valid for five minutes; submit_cut takes a context token from the video brief instead. A missing number stays missing.

It does not publish or schedule Reels, does not read private Instagram Insights, never asks for your Instagram login, and does not render video. Setup is three steps on the /agent.md page. Claude, Codex, Cursor, OpenCode and other remote MCP clients use the same endpoint, and you can revoke the key at any time.

Failure modes worth recognising early

The same mistakes return. Two variables in one test. A number without its age. An agent asked for a verdict when it should only report. A confirmation given once and never checked again.

Two are subtler: agent output as evidence in a pitch before a measurement exists, and an error message treated as an obstacle to route around. Codes such as unauthorized or confirmation_required are information.

None of this needs a special tool. It needs a boundary you can state in three sentences, a key you can take back, and a record you can still explain in six months.

Questions