Two FluentCart MCP Servers. Same Store, Different Jobs.

Running a shop means opening six admin screens to answer one question. Which orders need attention? What is running out? Which customer needs context before you reply? By the time you find it all, another order has arrived and WordPress wants an update. Lovely.

MCP gives an AI client a way to ask the store. There are now two routes: the official FluentCart MCP and the independent FluentCart MCP. Their names are similar. Their boundaries are not.

FluentCart MCP is an independent project; it is not the official server, an adapter for it, or a claim about FluentCart's roadmap. The independent server is optional and not required to use FluentCart or the official MCP. The useful question is not which logo wins a cage match. It is which boundary fits the work in front of you.

The Difference at a Glance

The table is deliberately not a scorecard. An official tool count, a source-registry count, and a client-visible count are three different things. Treating them as one number is how a comparison turns into a brochure with a calculator problem.

What the Independent Release Actually Claims

The independent server keeps its release facts in the generated release-contract.json. That record ties a package candidate to the tested protocol eras, compatibility profiles, and measured client surfaces. It is a better source than a sentence copied into an article and left here to fossilise.

The measured profiles record the client surface for each store fixture and write policy. Dynamic mode starts with a small discovery surface for reads; explicitly enabled reversible mode adds only its reviewed executor. Those are measured profiles, not a promise that every store, role, or configuration sees the same thing.

The source registry is broader than either profile. It is an implementation inventory used to build and prune the available surface; it is not a product claim and it is not dumped into a model's context by default. Route discovery and the WordPress principal decide what survives at startup.

The candidate record is similarly specific: candidate-bound automated handshakes are release evidence. Other-client recipes merely document setup; they produce no release evidence. A recipe is a recipe. A passing release gate is a passing release gate. The distinction should not need a chaperone, but apparently it does.

The Official Server Lives With the Shop

The official MCP follows FluentCart's native capability model. That is its great advantage: it belongs to the same product surface, uses its own permissions, and presents the workflows FluentCart chooses to expose.

If the task is a familiar operator question and the official server has the capability you need, that native path is usually the least surprising route. Check the FluentCart documentation for the capability and safety behaviour in the version you have installed; the official product owns those details.

That is not a weakness of the independent server. It is simply a different job. A standalone service cannot honestly borrow native claims from a product it does not ship.

The Independent Server Lives Beside the Shop

The independent server connects through FluentCart's authenticated REST surface and offers a separate MCP endpoint or local process. The additional configuration buys a different kind of work: route-aware discovery and analysis across several parts of the shop.

That is useful when the question crosses normal admin boundaries:

Which published physical products have no SKU, are below their stock threshold, and sold at least once this quarter?

The default dynamic surface discovers the relevant read capability instead of loading every possible schema in advance. Code Mode can combine approved reads and return the useful rows rather than every intermediate response. It remains read-only by construction.

The trade-off is simple: native FluentCart setup is shorter; the independent server gives you an additional configured service with an explicitly bounded, route-aware surface. Physics has not changed its mind on this.

What This Looks Like on a Tuesday

Start With the Work That Needs Attention

Shop owner: “What needs my attention today?”

The independent server can read the dashboard, relevant orders, stock context, and scheduled payments, then return a short prioritised answer. The default remains read-only, so asking a vague question cannot accidentally rearrange the business while you are making tea.

Investigate a Customer Problem

Shop owner: “A customer says they were charged twice. Check what happened.”

The server can find the customer, inspect related orders, and compare transaction records. It gives you evidence for a decision; it does not turn an investigation into a money-moving action. That boundary is intentional.

Delegate a Routine, Reversible Change

Shop owner: “Create coupon SUMMER25 for 25% off and make it expire on 31 August.”

In reversible mode, the server can handle the routine changes that meet its policy. That mode is off by default. The setup guide gets a connection working, while advanced configuration explains the switch; the release contract records the exact measured profile behind the claim.

Context Is a Choice, Not a Marketing Number

The independent server offers several modes because one client may prefer a small discovery surface while another prefers immediate access to a wider profile. The current release contract records the measured context and tool data for each profile. It is intentionally the authority for those numbers.

That means this article does not print a flattering token total and dare the next release to make it wrong. Dynamic mode trades a small initial surface for discovery calls. Wider modes trade more context for fewer discovery steps. Pick the one that suits the client and the task; pretending one is universally superior would save words but lose the plot.

The Safety Split

The independent server is read-only by default. Its reversible mode is for changes that meet the release policy. High-impact and destructive operations remain outside that surface in the current release.

So Which One Should You Use?

Use the official FluentCart MCP if you want:

• the shortest path inside FluentCart;
• native capability and permission behaviour;
• the workflows FluentCart has chosen to prepare and support.

Use FluentCart MCP if you want:

• route-aware read and analysis work across the connected store;
• route-aware discovery rather than a fixed universal surface;
• Code Mode for multi-step, read-only analysis;
• explicitly enabled reversible administration;
• a release record that separates source inventory, measured profiles, and client certification.

Start with the client chooser for the independent server. You can use both. Give them different server names and let each keep its own promises. Two MCP servers become confusing only when someone insists they are the same product. They are not, and that is rather the point.