Final Flows vs Store Builder
A side-by-side look at the Final Flows and Store Builder MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Final Flows for e-commerce work over a hosted endpoint; choose Store Builder for e-commerce as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Final Flows when
- You need dedicated capabilities in the E-Commerce domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: OAuth 2.0.
Choose Store Builder when
- You need dedicated capabilities in the E-Commerce domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
SB_API, SB_TOKEN, SB_SITE, SB_SITE_NAME, SB_EMAIL, SB_PASSWORD, PEXELS_API_KEYS. - You want tools like
sb_connect, sb_site_list, sb_api_find.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | E-Commerce | E-Commerce |
| Quality signal | 41/100 · Fair | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | OAuth 2.0 | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | SB_APISB_TOKENSB_SITESB_SITE_NAMESB_EMAILSB_PASSWORDPEXELS_API_KEYS |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 2 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | Not listed | 37 |
| Full listing | View Final Flows | View Store Builder |
Tools & capabilities
Final Flows tools
No tool names declared yet. Check the project README from the listing page.
Store Builder tools 37
sb_connectLog in and list the sites this account can operate. Call this first. Reads SB_EMAIL and SB_PASSWORD from the environment unless you pass them.sb_site_listList the sites this account can operate.sb_api_findFind API operations by intent (query), or get a call sheet (id): parameters, credential, body fields and handler caveats. Reaches all 892 operations.sb_api_callCall an operation from sb_api_find (id), or a route the catalog lacks (method+path); dry run by default. pick selects fields, max_items caps lists, item_offset skips items. Lists over 60 KB say so.sb_page_openOpen a page for editing and return its outline. Call before any sb_add / sb_set / sb_move / sb_remove. Find page ids with sb_api_find "list pages". Or form_id: edit that form's field document (fields, specials.formRules on its root).sb_page_repairRename a page root that is not "ROOT" (sppro_1, rt_<hex> — left by older seeds) to ROOT, for one page or, without page_id, every page on the site. Draft only; a published page is listed for re-publishing. dry_run (default true) lists what would change.sb_outlineThe open page as a compressed tree — id, type, name, child count, band, and whether a node is a shared global or a site overlay. Never the raw document: a real page is hundreds of KB of JSON.sb_node_readOne node in full — style, config, specials, per-breakpoint overrides, bindings.sb_catalog_searchFind an element type by what it does — or OMIT query to browse every type, the only way to meet one you would not have searched for. detail:true adds the AI hints, as does sb_traits_for. query "icon:<word>" lists icon names.sb_traits_forThis element's INSPECTOR, as a person sees it: tabs, groups, and every control name — with what each DECLARED control writes, and the AI hints for using the element. Read this before styling an element; pass control to read one control in full.sb_addAdd an element — or a whole NESTED subtree — under a parent. One call builds a complete section: pass children rather than calling this once per node.sb_setWrite style, config or specials keys on one node, or on many through edits (one save, one live frame). Per BREAKPOINT by default; base:true writes the fallback layer, right for a value that should not vary.- +25 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Final Flows
{
"mcpServers": {
"final-flows": {
"url": "https://ai.finalpos.com/mcp"
}
}
}
Store Builder
{
"mcpServers": {
"store-builder": {
"command": "npx",
"args": [
"-y",
"sbuilder-mcp"
],
"env": {
"SB_API": "YOUR_SB_API_HERE",
"SB_TOKEN": "YOUR_SB_TOKEN_HERE",
"SB_SITE": "YOUR_SB_SITE_HERE",
"SB_SITE_NAME": "YOUR_SB_SITE_NAME_HERE",
"SB_EMAIL": "YOUR_SB_EMAIL_HERE",
"SB_PASSWORD": "YOUR_SB_PASSWORD_HERE",
"PEXELS_API_KEYS": "YOUR_PEXELS_API_KEYS_HERE"
}
}
}
}
Frequently asked questions
Final Flows is categorized under E-Commerce and uses a remote HTTP/SSE transport. Store Builder belongs to E-Commerce and uses a local stdio subprocess. Pick Final Flows for e-commerce work and Store Builder for e-commerce.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Final Flows has no declared pricing — check the project's own site. Auth: oauth 2.0. Store Builder has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add final-flows and store-builder as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Final Flows has a quality signal of 41/100 (Fair) with 2 views, 0 installs and 0 GitHub stars. Store Builder has 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars.
