Imagine the owner of a small tea shop. It is the evening before a holiday week, energy is gone, and gift set prices need to go up. They open an app with an AI agent and type one line: “Raise gift set prices by ten percent.” The agent politely says the job is done. In the morning they learn that “sets” in the catalog also covers tableware sets, and those went up too.
In this story nobody made a mistake in the usual sense. The agent did exactly what it understood; the owner said what they meant. Situations like this, to me, are the main practical question around MCP. No machine uprising involved. The tool really cuts routine. The question is who checks the outcome and how.
What Tilda MCP is in plain terms
MCP is an open protocol that lets an AI agent connect to external services and act inside them. In its September release Tilda introduced its own MCP server: you can hook Claude, Copilot, Cursor or another agent to your account, and it will run tasks on your behalf. The release lists creating and editing pages, managing products, and adding blog posts.
It sounds like hiring someone you can talk to in normal language. I like the comparison, with a caveat: this employee does not always ask for clarification unless you ask it to. It does not know you have two kinds of “sets” in the catalog until you say so or it thinks to check.
What the agent can do today
Tilda openly calls this the first version of the MCP server. Per the release, the agent now works with standard blocks, Zero Block, the Store, and Feeds; CRM, member area, internal analytics and other modules are promised later. Connection docs add conditions: the MCP server is on Personal and Business plans, and you can only connect it to an agent installed on the device as an app. A cloud agent in the browser will not work.
The docs describe capabilities broadly: the agent can create Feed posts, add products to the Store, and create pages. Tilda also says you can turn the MCP server into a store manager or an assistant that finds and fixes SEO issues. I would read that as a list of available actions, not a guarantee every task will be right the first time. Tilda does not promise that either.
An access key as a job description
The most useful part of the docs, to me, is access keys. Each connection gets a key with a name, access type, project, and expiry. Access can be full or limited; with limited access you pick modules and actions the agent may use. The release gives an example: one agent only on the Store, another only on Feeds.
That is a lot like a job description for a new team member. Who fills the blog does not need price access. Who updates stock does not need to edit the homepage. The narrower the rights, the smaller the blast radius of a mistake; in the tea story a key limited to one catalog section would not have touched tableware.
There are technical details worth knowing upfront. Key lifetime runs from one hour to indefinite, and you cannot change it later—only delete the key and create a new one. The key is shown once, so store it somewhere safe immediately. The key list also marks whether an agent used the key. For a one-off task a short lifetime beats indefinite access everyone forgets to revoke six months later.
Order first, then the agent
Agents work more easily on sites with clear section names, filled product fields, and consistent page logic. If you are not there yet, start by tidying structure and content, then decide which routine to hand to automation.
Where humans should keep the final say
The MCP protocol itself is fairly clear on this. The tools specification says you should always keep a human in the loop who can reject a tool call, and apps are advised to confirm before operations. That is guidance for apps that connect agents; how each app follows it is worth checking in that app.
I would split tasks into two buckets. First—easy to spot and undo: a draft post, a new page nobody has seen yet, a product description for review. Here the agent saves time and a human skims the result. Second—what buyers see at once or what is hard to roll back: prices, stock, publishing, bulk catalog changes. Human confirmation before action is worth those extra thirty seconds.
How to catch a mistake before customers do
Bulk changes are tricky because they look like one action. The owner wrote one sentence and forty cards changed. A good habit is to ask the agent to list what it will change first, then execute. Even simpler: start with a small sample—change three prices, check the live page, then apply the rule to the whole section.
Site prep helps too. Clear section names, filled attributes, and consistent page logic matter to an agent like a new hire. If automation runs into links with external systems, accounting, or custom logic, that is separate development work, and one prompt is a poor way to solve it.
MCP can still save our tea shop owner many evenings. Next time, limit the key to the “Gift sets” section and ask the agent to list products before changing prices. A dull habit, but the tableware keeps its old price.