Every vendor drew the same line

impact.com's MCP server exposes 26 tools to an AI assistant. Exactly 1 of them writes anything - creating a tracking link, and only on the partner side. The brand side is entirely read-only.

The guardrails are written into their own documentation. The tool that lists partners is explicitly "not for approving/declining applications". The tool that lists tasks is explicitly "not for creating or updating tasks".

And the skill that surfaces reversals and rejections - the closest thing in the whole product to validation work - says this:

"For processing actual pending actions or ops triage, use your impact.com platform dashboard instead."

The same holds elsewhere. Everflow's MCP is read-only by architecture. Affise states plainly that its toolset is "read-only by design".

impact.com now markets an add-on it describes as helping agents "execute actions on top of your MCP Tools". Worth reading closely: a skill there is an instruction set, not a permission. The tool schema behind it is unchanged, still 26 tools and still 1 writer, and the skills that come closest to settlement end by sending you back to the dashboard.

Every vendor arrived at the same boundary independently, and it falls exactly where a financial consequence becomes disputable.

That is a liability gap, and liability gaps do not close next quarter.

What I could not establish

PartnerStack describes "read and act" on a marketing page. I could not find a published tool schema or permission model behind it.
Rakuten's Mirai agent writes offer configuration, but no technical documentation or statement of autonomy limits has been published.

Sources

impact.com Integrations Hub, Brand MCP ToolsRead at source 28 August 2026
The brand-side tools and the published guardrails, including the exclusions on approving applications and on creating or updating tasks.
impact.com Integrations Hub, MCP Quick StartRead at source 28 August 2026
How the server is described to a customer.
Everflow, MCP server documentationRead at source 19 August 2026
Read-only by architecture: 16 tools, none of which write, scoped read-only keys, and explicit write protection.
Affise, MCP server documentationRead at source 19 August 2026
25 tools at the time of checking, and the statement that the public toolset is read-only by design.
impact.com, brand API reference: Action Inquiries, Contracts, Partners and Action UpdatesRead at source 19 August 2026
The 5 actions that matter and whether any of them can be reached. The dispute-resolution endpoint exists in the REST API and is deliberately not exposed through MCP, and there is no endpoint at all for creating an inquiry programmatically.
PartnerStack, AI platform marketing materialRead at source 19 August 2026
The claim of read and act, made on a marketing page with no published tool schema, no permission model and no approval workflow. Claimed rather than documented, which is why it sits in the gaps rather than in the finding.

Every source carries the date it was read. Where there is no link the document is held on file and cited by publisher and title.

My read

They all arrived at the same boundary independently, and it falls exactly where a mistake becomes a financial dispute rather than a reporting error. That is not caution for its own sake. It is a liability line, and liability lines do not move because a roadmap says so.

What I'd do with this

If a vendor tells you their agent can act rather than observe, ask to see the tool schema and the permission model. Not to catch anybody out. To find out which side of that line the product actually sits on, because it changes who carries the risk.

Can your operations carry the growth you're planning?

Follow a transaction from the moment it happens to the moment everyone has been paid. Then find the place it stopped.

Get in touch

Find where the money stands still