TikTok launched Agentic Hub on June 30, 2026, a marketplace where advertisers browse ready-to-use first-party and third-party AI Skills covering campaign creation, creative generation, performance analysis, audience insight, and catalog management. TikTok’s launch announcement names publishers including HubSpot, Wix, Constant Contact, and Mobvista. The Hub is built on the TikTok for Business Model Context Protocol (MCP) server.
The connector and the marketplace are different layers, and you do not govern them the same way. TikTok now documents its MCP server as a bridge that packages approximately 400 TikTok API for Business endpoints as tools for campaign management, reporting, catalogs, creative, audiences, and Business Center administration.
TikTok says advertisers can use its MCP connection without handling API credentials, coding, or complex setup. TeamAI provides a user interface for registering an external MCP server as a workspace tool. Authentication requirements still depend on the server being connected, so some teams may need technical help with credentials and permission design. The harder question is what your record of agent actions needs to contain before any of those tools can touch live budget.
Four layers sit between an agent and your ad budget
Most write-ups treat MCP as a single thing. It is four, and knowing which layer you are looking at determines where your log has to sit.
The third row is the one that catches teams out. If you log only the Skill request, one entry can hide several distinct changes to campaigns, ad groups, ads, or budgets. Log each resulting account action and reconcile those actions back to the request.
TeamAI sits above all four as the orchestration layer. Your agent, its instructions, its grounded knowledge, and its registered tools live in the workspace, and you can register an external MCP server as a workspace tool from Tools, then Create Tool, then the MCP Server type. TeamAI is not TikTok Ads Manager and does not replace it. TikTok Ads Manager and TikTok API for Business stay the systems of record, and TikTok’s own permission model still decides what any call is allowed to do. What the workspace gives you is one governed place where the agent, the connection, and the human review step sit together instead of scattered across personal accounts.
The read and write taxonomy that should drive your scope
Nearly every credible piece on this topic lands on a read versus write distinction. That distinction is correct and too coarse to scope a permission against. Four classes are more useful.
The class teams misjudge is the third one. Reversibility is not a property the platform grants you. It is a property you create by capturing the prior value before the call executes. If nobody recorded what the budget was at 9:14 that morning, the change was not reversible, whatever the interface suggests. Write that down as a rule before you write it down as a field.
Google’s official Analytics MCP server is a clean example of the first class and a useful place to start a read-only connection. Its credentials require the analytics.readonly scope, so the connection does not receive Analytics write permission. Google labels the server Experimental, and the repository describes it as a local server, so setup requires local tooling and Google credentials rather than a hosted no-code connection.
A public tool catalog does not replace outcome verification
TikTok now publishes an extensive MCP tool catalog and a changelog. That closes the documentation gap. It does not remove the need to verify what happened inside the ad account.
An accepted tool call proves that the platform processed a request. It does not prove that the resulting object, value, or delivery state matches what the approver intended. Keep two fields in the record.
First, record intended state and observed state as separate fields, permanently, not just during a pilot. Intended state is what your workflow asked for. Observed state is what you confirmed in TikTok Ads Manager afterwards. When those two disagree, you want the disagreement visible in the record rather than reconstructed from memory.
Second, hand-verify the first several writes of every new Skill in TikTok Ads Manager before you rely on it for recurring actions. Repeat that verification after a relevant tool or platform update. This is outcome validation, not a substitute for documentation.
Least-privilege scope with the controls that actually exist
Scoping advice usually stops at “use minimum permissions.” The useful version names the specific controls and, more importantly, what each one does not cover.
Read the right-hand column twice. It is the honest shape of this problem: the workspace can govern who connects what and where the credential lives, and it cannot govern whether a change was a good idea. That judgment stays with a person, and your ledger is how you prove a person made it.
One more honest note from TeamAI’s own documentation: remote MCP connections are still evolving technology. The setup guidance recommends restarting the client or temporarily disabling and re-enabling the server if a connection fails. Build your first connection when you have time to test it, not an hour before a campaign launch.
What a per-action ledger should actually contain
“Keep an approval log” is advice nobody can execute. Here are the fields.
Two of these get dropped almost every time, and they are the two that carry the audit.
prior_value is the first. It is the difference between a change you can undo and a change you can only describe.
The approved_at and executed_at split is the second. Keeping one timestamp lets “a human reviewed this” and “a human was told afterwards” collapse into the same row, and once they collapse you can no longer tell which kind of workflow you built.
Approved before is not the same status as notified after
Three approval statuses, not two.
Approved before execution means a person released the action. Notified after execution means the action happened and a person can now react. Unreviewed means nobody looked. These carry genuinely different risk, and a log that records the second as “reviewed” is worse than no log, because it produces false confidence in an audit.
If the honest answer for a given workflow is notified after execution, record that. Then decide whether the action class justifies it. Reads and draft-only writes usually do. Live budget changes usually do not.
TeamAI’s Automated Workflows are where the before-approval pattern gets built: chain the analysis steps, route the output for a human decision, and place the write call behind that step rather than in front of it. The draft-then-review shape is the same idea at the content layer, where the model’s output stays inside the workspace until a person releases it. For API-type connections and the plugin builder specifically, Custom Plugins covers the setup path this page does not repeat. The workspace can route your approval, but the connected platform’s permission system remains the final limit on what the credential can do.
Multi-model routing helps on the analysis half of these workflows, where the TeamAI FAQ lists access to more than twenty leading models across providers, so the reasoning step and the drafting step do not have to run on the same model. Routing has no bearing on write safety, and it is worth keeping those two decisions separate in your own head.
A recheck cadence tied to action class, not the calendar
A quarterly review of everything is how drift survives. Tie the cadence to what the connection can do.
Two triggers override this schedule: adding a new Skill, agent, or token to an existing workflow, and any relevant platform or MCP changelog update. Both call for an immediate re-review, not a wait for the next cycle.
Two triggers override the schedule. Add a new Skill, agent, or token to an existing workflow and re-review immediately rather than waiting for the cycle. Re-verify after any relevant platform or MCP changelog update, because tool behavior and supported actions can change.
The failure pattern this prevents is boring, which is why it works. A team wires a write-enabled agent, scopes it carefully, reviews the first few actions closely, and then the review slips as other priorities take over. The agent keeps acting inside its permitted scope, so nothing looks broken in any single moment. Three months later nobody can say what changed across that stretch. The scope was never the problem. The maintained record was.
Where this stops being a workflow problem
If you are governing one channel, build this yourself. The ledger above is a spreadsheet, the read-only and draft-then-review tiers are worth wiring regardless of what you decide about live writes, and TeamAI gives you one workspace where the agent, the connection, the credential, and the approval step sit together instead of in four places. Plan gates for MCP connections are on pricing. TeamAI’s enterprise page says WebFX uses the workspace across its organization of more than 500 employees and includes a CEO statement that hundreds of employees share prompts and models there.
If you are governing several channels, the harder question is a different one. The cited Google, Meta, and TikTok product documentation describes each platform’s own capabilities. It does not establish one shared authority that adjudicates budget decisions across all three. That is a coordination problem rather than a permission problem, and it is worth reading who is coordinating agent decisions across your ad platforms before you scale a workflow past one account.
One fork worth naming plainly. If what you actually want is somebody else accountable for paid media outcomes rather than a workspace your own team governs, that is Growth Loops, the managed paid marketing program on teamai.com. Different product, different buyer job, and not what this page is describing.
Ready to build the governed version? Start in TeamAI, register your first read-only MCP connection, and put the ledger in place before you ever grant a write.
Start in TeamAI