Imagine publishing an article to your website without ever opening WordPress. You type what you want into a chat box on your phone. Sixty seconds later it is live — written, formatted, SEO fields filled, published.

That is working right now, and MCP connectors are the reason.

The surprise is not that it got faster. It is that a step you have repeated for years simply stopped existing.

What MCP Connectors Actually Are

MCP stands for Model Context Protocol, an open standard originally released by Anthropic and documented at the Model Context Protocol site.

Think of USB. One standard meant any device could plug into any computer without a custom driver. MCP is that idea, for AI and software.

A connector is the plug for one specific tool. WordPress has one. GitHub has one. So do Slack, Notion, Google Drive and hundreds more.

Without a connector, the AI is a good writer trapped in a box. It hands you text and you carry it.

With a connector, the AI is inside the tool. It reads, checks and acts.

Not Automation. No Workflow At All.

For years, the answer to a repetitive task was to build an automation. Wire up n8n or Zapier. Trigger here, action there, map the fields, maintain it forever.

What that machine really did was carry things between tools that could not talk to each other.

Connectors close that gap. There is nothing left to carry.

So this is not a lighter automation platform. It removes the layer. No trigger, no action, no pipeline. The workflow does not get optimised — it is gone, and what remains is a single task: say what you want.

One honest exception. High-volume scheduled jobs still belong in a real automation platform. But the messy one-off work that fills most days was always a bad fit for pipelines.

Why the Output Does Not Come Out Generic

The connector reads your existing posts first, so it learns your formatting and matches it.

It checks your real categories, with real IDs. No guessing.

It writes SEO fields straight into the correct plugin fields, because it can see those fields exist.

It fills custom meta boxes in the same pass.

Then it publishes, or saves a draft for review. Nothing pasted. Nothing carried. That is the gap between an AI that writes and an AI that operates.

MCP Connectors Mean a Phone Is Enough

This is the part that surprises people, so here it is bluntly. Sitting in a corridor between meetings with no laptop nearby is now a completely workable place to publish from.

Not a stripped-down companion app. The same connector, the same access, the same publish.

And the knowledge requirement drops to almost nothing. You do not need to know where the SEO plugin hides its settings, what a slug is, or which category ID maps to what.

You do not need to know WordPress. You need to know what you want published.

For Coders, It Goes Further

Assistants now work inside VS Code rather than beside it. The AI reads your real files, understands your project, and edits code in place.

Claude Code runs from the terminal across a whole codebase. Give it a task and it reads the relevant files, changes several at once, and runs commands. It supports MCP servers too.

The GitHub connector handles repos, code search, issues, branches and pull requests from the conversation.

Stack those and the editor, repo, tracker and terminal collapse into one surface. Building a portfolio site or a landing page becomes a conversation rather than a setup process.

A woman working at a table with a tablet and phone, managing her site without a dashboard

Connectors Worth Knowing

WPVibe — self-hosted WordPress. Posts, pages, custom fields, categories, media, plugins, WP-CLI. Full read and write.

WordPress.com connector — official, for hosted sites.

GitHub — repos, issues, branches, pull requests.

Apify — scrapers and data collection for competitor research.

Jam — bug reports with console logs and session recordings.

The list grows monthly. Every tool that adds a connector joins the same window.

Your First One, in Four Steps

1. Check your assistant supports connectors. Not every plan does, and this changes often.

2. Pick one connector for one real problem. Choose the tool you open most and resent most.

3. Start read-only. Ask it to list your drafts. This proves it sees the real site.

4. Then let it write something small. A draft. A typo fix. Build up.

The Honest Limits

Permissions are real. Start with drafts and review output before granting more.

It is execution, not judgement. What to publish and whether it is good is still entirely you.

Some work wants a desktop. Heavy design and serious refactoring need screen space.

Connector quality varies. Test low-stakes first.

Look Back at What You Used to Do

Now that the new way is clear, look at the old one properly.

The idea took two minutes. Then came the rest. Open dashboard. Log in. Paste. Fix the formatting the paste broke. Scroll to the SEO plugin. Meta title. Description. Focus keyword. Category. Slug. Featured image. Preview. Publish.

The AI did the two-minute part. You did the fifteen-minute part, every single time.

The bottleneck was never writing. It was handling — and handling multiplied with every site you ran.

The Real Shift

Running a website used to mean knowing where things lived. Which menu, which tab, which setting. That knowledge was a wall, and it kept out plenty of people with good ideas and no patience for dashboards.

Connectors move the skill. Not knowing where the setting is. Knowing what you want.

Pick one tool. Wire up one connector. Do one real task with it.

For a worked example of what gets built once the friction is gone, try the free AI workflow generator on this site. And before adding any new tool to your stack, run it through four filters first.

What’s Really Happening Behind the Chat Box

The interesting part isn’t the chat box itself.

A chat interface is simply the front door.

Behind it, there can be several different systems working together.

One instruction might involve a website builder.

Another might involve a store or database.

Another might involve code.

Another might involve an API.

And another might simply require the AI to explain what needs to happen next.

This is where AI becomes much more interesting than a traditional chatbot.

The interface is conversational, but the work underneath can be technical.

Instead of navigating through five different dashboards, a user can increasingly describe an outcome in ordinary language and let the underlying tools handle some of the implementation.

That doesn’t mean every task can be completed from a phone.

It means the distance between an idea and an executable instruction is becoming much smaller.

From conversation to action

Imagine starting with a simple request:

“I want a landing page for my new digital product.”

Traditionally, that could mean opening a website builder, choosing a template, creating sections, writing copy, uploading images, adjusting the layout and eventually publishing the page.

With an AI-assisted workflow, the first step can be conversational.

I can describe:

  • what the product does,
  • who it is for,
  • what the page should look like,
  • which sections I need,
  • what call-to-action I want,
  • and what information should appear above the fold.

AI can then turn that description into a structure.

But this is where expectations need to remain realistic.

Generating the first version is not the same as finishing the website.

Someone still needs to inspect the result.

Is the layout readable?

Does it work on mobile?

Are the links correct?

Is the copy accurate?

Does the checkout work?

Are the images properly licensed?

Does the page load correctly?

AI can accelerate the process.

It doesn’t remove the need for testing.

Your store is another layer

The same idea becomes even more interesting when commerce enters the picture.

A store isn’t simply a collection of product pages.

There can be:

  • product information,
  • pricing,
  • inventory,
  • payment processing,
  • shipping,
  • customer accounts,
  • order management,
  • email notifications,
  • analytics,
  • refunds,
  • taxes,
  • and customer support.

An AI interface can help with parts of that workflow.

For example, a store owner might ask:

“Create a product description for this new product using the information in my product notes.”

Or:

“Summarize the most common questions customers have asked about this product.”

Or:

“Help me identify which product pages need better descriptions.”

These are useful applications because the AI is working with information that already exists.

The mistake would be assuming that a conversational interface means the underlying business infrastructure has disappeared.

It hasn’t.

The payment processor still has to process the payment.

The store still needs accurate product data.

The website still needs hosting.

And customer information still needs to be handled responsibly.

The chat box is the interface.

The infrastructure underneath is still real.

And then there is the code

This is where the idea gets particularly powerful.

A person who doesn’t want to manually write every line of code can describe what they want in natural language.

For example:

“Add a contact form to this page.”

Or:

“Change the navigation menu so that it works better on mobile.”

Or:

“Create a simple calculator that takes these three inputs and returns the result.”

AI can generate code, explain existing code, identify errors and suggest modifications.

That can dramatically lower the barrier to experimentation.

But there is an important catch.

Code that looks correct isn’t necessarily code that is correct.

A generated application still needs testing.

There may be:

  • logic errors,
  • security problems,
  • incorrect assumptions,
  • broken dependencies,
  • accessibility issues,
  • performance problems,
  • or edge cases that weren’t considered.

This is why I don’t think AI makes technical knowledge irrelevant.

In many situations, it makes technical understanding more valuable.

If I understand the basics, I can tell when an AI-generated solution looks suspicious.

If I don’t understand the system at all, I may not know that something is wrong until a user discovers it.

The phone is powerful, but it isn’t magic

The idea of building a website, store or application from a mobile chat interface sounds almost futuristic.

And sometimes it genuinely feels that way.

But there is a practical distinction between controlling a workflow from a phone and doing every part of the workflow entirely on a phone.

Those are not the same thing.

A phone is excellent for:

  • giving instructions,
  • reviewing drafts,
  • checking notifications,
  • approving changes,
  • editing short pieces of content,
  • monitoring a workflow,
  • communicating with an AI assistant,
  • and making quick decisions.

A desktop is often still better for:

  • complex debugging,
  • detailed visual editing,
  • large codebases,
  • spreadsheet-heavy work,
  • design work,
  • configuration,
  • and long technical sessions.

That doesn’t make the mobile experience less impressive.

It simply puts it into perspective.

The real breakthrough isn’t necessarily:

“I never need a computer again.”

It is:

“I can continue moving the work forward even when I’m away from my computer.”

That’s a much more useful promise.

The new workflow: idea → instruction → implementation → review

I think this is the simplest way to understand the shift.

1. Idea

Something needs to be created, changed or solved.

2. Instruction

The user explains the desired outcome.

3. Implementation

AI and connected software perform some portion of the work.

4. Review

The human checks the result.

5. Correction

Anything that doesn’t work is fixed.

6. Deployment

The final version goes live.

That last part is important.

The AI isn’t the entire workflow.

It is one layer inside the workflow.

Why the review step matters so much

AI can be extremely convincing when it is wrong.

That’s one of the biggest differences between traditional software and generative AI.

If a calculator says:

2 + 2 = 5

the error is obvious.

If an AI-generated product description contains a subtle factual error, the sentence can still sound perfectly professional.

If AI-generated code contains a security vulnerability, the application can still look beautiful.

If an AI creates a store workflow with the wrong assumption about inventory, the interface may still appear to work.

This is why human review shouldn’t be treated as a failure of AI.

Human review is part of the system.

What makes the mobile approach useful?

The biggest advantage may actually be psychological.

When creating something requires opening a large development environment, configuring multiple tools and remembering a long list of technical steps, a small idea can easily remain an idea.

A conversational interface lowers the activation energy.

You can have an idea while sitting somewhere completely different from your desk.

You can describe it.

You can ask questions.

You can explore alternatives.

You can ask the AI to explain a technical concept.

You can decide what to build next.

That matters.

Because sometimes the biggest obstacle isn’t technical complexity.

It’s friction.

But convenience creates another risk

When software becomes easier to control, it becomes easier to make changes without fully understanding their consequences.

That’s why I would be careful about giving AI broad permissions.

For example, there is a major difference between asking an AI:

“Explain how I should change this.”

and:

“Change everything for me.”

The second instruction may be convenient.

But it also gives the system much more responsibility.

For production websites, stores and applications, permissions should be limited wherever possible.

A sensible workflow is:

Draft → Review → Approve → Deploy

rather than:

Ask → Automatically change everything

The more important the system, the more valuable this distinction becomes.

Security cannot be an afterthought

If AI can access a website, store, database, codebase or external service, security becomes part of the conversation.

Never treat an AI assistant as automatically trustworthy simply because it is convenient.

Think about:

  • API keys,
  • passwords,
  • payment information,
  • customer data,
  • private documents,
  • database credentials,
  • administrator permissions,
  • and production access.

Sensitive credentials should not simply be pasted into a conversational interface because the AI needs them to complete a task.

Where possible, use proper authentication mechanisms, restricted permissions and separate environments for testing and production.

The goal should be to give the AI only the access it actually needs.

The best use case may be the smallest one

There is a temptation to demonstrate AI by building something spectacular.

A complete website.

A full ecommerce store.

An autonomous application.

A sophisticated AI agent.

But sometimes the most useful application is much smaller.

Maybe the AI helps update ten product descriptions.

Maybe it creates the first draft of a landing page.

Maybe it finds an error in a piece of code.

Maybe it turns a rough idea into a technical specification.

Maybe it explains why a WordPress setting isn’t working.

Those small improvements can accumulate.

You don’t need an autonomous company to benefit from AI.

You need a workflow that removes friction.

A practical example

Imagine a freelancer receives a message from a client:

“Can you create a simple landing page for our new service?”

Instead of immediately opening a website builder, the freelancer could use an AI assistant to structure the project.

Conversation

The freelancer explains:

  • the target audience,
  • the service,
  • the desired tone,
  • the call-to-action,
  • the required sections,
  • and the brand guidelines.

Planning

AI turns the conversation into a page structure.

Creation

The freelancer uses the appropriate website or development tool to create the page.

Review

The freelancer checks:

Delivery

The final website is published.

Notice what happened.

The AI didn’t replace the freelancer.

The freelancer simply spent less time translating an idea into a starting structure.

That’s the more realistic version of AI-assisted work.

What happens when everything becomes conversational?

This is where the idea gets bigger.

For decades, software has largely required users to learn the software’s interface.

Buttons.

Menus.

Dashboards.

Commands.

Settings.

Forms.

AI introduces another possibility:

The software can begin learning how humans naturally express intent.

Instead of asking:

“Which menu contains the setting I need?”

I can potentially ask:

“Make the homepage show the three newest products.”

That’s a very different interaction model.

The underlying software still exists.

But the interface becomes conversational.

And that could eventually change how people interact with a large number of digital systems.

But natural language has limits

Human language is wonderfully flexible.

It is also wonderfully ambiguous.

Consider:

“Make the website look more professional.”

What does “professional” mean?

More whitespace?

Different typography?

Fewer colors?

A corporate appearance?

A luxury appearance?

A more modern layout?

There is no single technically correct answer.

That is where human taste enters the workflow.

AI can generate options.

The person still has to decide what “better” means.

The real magic is the combination

The title of this article talks about a website, a store and code coming together through one mobile chat box.

But the deeper idea is not the chat box.

It is the combination of several technologies:

AI + software + APIs + automation + cloud infrastructure + human judgment.

Each component does something different.

AI interprets and generates.

Software executes.

APIs connect systems.

Automation moves information.

Cloud infrastructure provides the underlying environment.

The human defines the objective and evaluates the result.

That’s the actual architecture.

Where this could go next

The next step isn’t necessarily better chatbots.

It is better interfaces between AI and software.

Imagine telling an assistant:

“The new product is ready. Add it to the store, prepare the product page, create three promotional variations, update the launch checklist and show me everything before publishing.”

Today, some parts of that workflow can already be accomplished with combinations of software and automation.

But the workflow still requires configuration, permissions and review.

As these connections become easier to build, the conversational interface could become a kind of control layer over multiple applications.

That is where things become genuinely interesting.

What I would still keep human

Even in a highly automated workflow, I would keep certain responsibilities firmly with the person running the business.

The idea

Why are we building this?

The strategy

Who is it for?

The priorities

What should be done first?

The quality standard

Is this actually good enough?

The final approval

Should this go live?

The responsibility

What happens if something goes wrong?

AI can assist with all five.

But assistance isn’t ownership.

That distinction becomes more important as AI systems gain access to more tools.

The lesson isn’t “AI can do everything”

If there is one thing I would change about the way AI-assisted building is discussed, it is this:

Stop measuring the technology by how much human work it can eliminate.

Measure it by how much useful work it can unlock.

Those are different things.

A tool that removes ten minutes of repetitive work may be more valuable than a spectacular demonstration that generates an entire website but requires two hours of debugging.

A simple automation that runs reliably every day can be more useful than an autonomous agent that occasionally does something impressive and occasionally does something completely wrong.

Reliability matters.

Control matters.

Usefulness matters.

From mobile chat box to personal command centre

That’s why I find this direction so interesting.

The mobile chat box may eventually become more than a place to ask questions.

It could become a lightweight command centre for personal digital work.

Not because the phone suddenly contains every piece of software.

But because AI can potentially act as an interface between the person and those systems.

The user says what needs to happen.

The connected tools perform the appropriate actions.

The user reviews the result.

And the cycle repeats.

That could make sophisticated digital workflows feel much more accessible.

But the best systems will still have boundaries.

They will know what they are allowed to change.

They will know when to ask for approval.

And, most importantly, they will make it easy for a human to remain in control.

Wrapping Up

The most exciting part of this technology isn’t that I can type into a chat box and ask for a website.

It is that the boundary between thinking about something and starting to build it is becoming thinner.

An idea can become a specification.

A specification can become a prototype.

A prototype can become a website.

A website can become a store.

Code can connect the pieces.

Automation can move information between them.

And AI can sit across parts of that workflow, helping translate human intent into digital actions.

We’re not at a point where one mobile chat box can reliably replace every developer, designer, marketer, store manager and system administrator.

And I don’t think pretending otherwise is useful.

The more interesting future is one where a person can remain the director of the system while AI and software handle increasingly large portions of the execution.

That is the real magic.

Not that the machine does everything.

But that one person can do more with the right system.

And perhaps that is what the next generation of software will feel like:

Less clicking through applications.

More telling your tools what you want.

Less memorizing where a setting lives.

More describing the outcome.

Less friction between an idea and a prototype.

And, hopefully, more time spent on the part of the work that still needs a human being.