NorthCinder: an MCP shopping server that compares offers and asks before it buys
Open-source MCP server for comparing products and asking the buyer before purchase.
At a glance
- What is it?
- NorthCinder is a self-hosted Model Context Protocol server that gathers product offers from store adapters you configure, ranks them with a spec you can read, and requires a one-time signed approval before any checkout. The interesting part is the approval boundary; the weak part is that the project itself says no host and model combination is currently qualified for routine research.
- Who is it for?
- Adopt NorthCinder if you want an MCP shopping server whose ranking rules and audit log live on your own machine and whose checkout path refuses to run without a fresh, single-use approval tied to one exact offer. Do not adopt it if you need full-market coverage or unattended purchasing, because store access is limited to the built-in adapters and the README states that no host and model combination is currently qualified for routine research.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 24 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem NorthCinder is aimed at
Marketplace shopping agents have a structural conflict. The same party that decides which products are visible also earns money when the sale closes. NorthCinder's README states the position plainly: an agent that searches one catalog and steers the buyer toward that platform's checkout "is not independent advice." The project is a response to that, not a general product search tool.
It is built for people who already run an MCP-capable AI app and want product comparison to happen against sources they picked, with the reasoning exposed. The README frames the audience as buyers who want to see where facts came from and who want a say before money moves. The repository owner operates no NorthCinder service, there is no account, and no cloud component sits in the path. That is a deliberate design constraint rather than a missing feature.
If you are shopping for a single item on a single site, NorthCinder is more machinery than the task needs. Its value shows up when offers span several stores and you care about which one ranked first and why.
What actually runs on your machine
Your AI app talks to NorthCinder over MCP. In the default local mode, the MCP server and the search engine run together in one process on a temporary loopback port, and the mode is keyless. Ranking is rerun locally before a result is returned, and recommendations, approvals, and checkout attempts are written to a local audit log.
Store access is adapter-based. The repository ships built-in adapters for Shopify, WooCommerce, eBay, Etsy, and a read-only Amazon comparison adapter, each with its own README under adapters/. When a store was unavailable or not configured, NorthCinder is supposed to say so rather than present a partial search as full-market coverage. That distinction matters more than it sounds: a comparison tool that quietly omits half the sellers produces confident answers from incomplete input.
The trust surface is documented in separate files rather than only in prose. docs/RANKING.md, docs/TRUST.md, docs/NEUTRALITY-AUDIT.md, and packages/checkout are named as the places where ranking, trust, neutrality, and checkout behaviour are specified. Those documents are the thing to read before believing any claim about how sponsored offers are handled.
Research plans gate what gets compared
NorthCinder separates research from ranking, and the separation is enforced. Before researching, the MCP host is expected to read northcinder://research/product or northcinder://research/seller, then call create_research_plan with the actual request and the exact subject, then follow the returned checklist using research tools the host already controls. NorthCinder does not supply the browsing itself in that flow; it supplies the plan and the structure.
Two rules follow from this. First, if sources disagree or fail to identify the exact product or seller, the result stays provisional. Second, research can decide whether an offer is ready to compare but cannot add ranking points. That second rule is the one worth pausing on, because it prevents a well-researched listing from gaining an advantage purely through effort spent on it.
The README is blunt about the current state: "No host and model combination is currently qualified for routine research use." That sentence should shape how you deploy this. Treat every research result as provisional until a human checks identity, sources, conflicts, and unknowns. An implementation that ships this warning in its own README is telling you where it expects to fail.
Getting it running: npx northcinder init and the local default
The quick path needs Node.js 20 or later and an MCP-capable AI app. One command does the setup:
npx northcinder init
That saves configuration on your computer and prints the MCP entry your AI app needs. Local mode is keyless and needs no service URL. Once the host is connected, a brief like "Find black wool running shoes under $130. Compare price, delivery, fit, and merchant trust. Tell me why the winner ranked first and which options were ruled out" exercises the ranking explanation path.
Building from source is a pnpm workspace. Product packages need Node.js 20 or later; the private site workspace needs Node.js 22.12 or later. The README gives these commands:
corepack pnpm install --frozen-lockfile corepack pnpm build node northcinder/bin/northcinder.js init
If you run the engine separately instead of in local mode, the service takes NORTHCINDER_API_KEYS, and the client is configured with NORTHCINDER_SERVICE_URL plus a matching NORTHCINDER_CLIENT_KEY bearer credential. Non-loopback bearer connections must use HTTPS. The README recommends local mode for most people, and the extra configuration is the reason: splitting the engine out buys you a network hop and a credential to rotate, not additional capability.
Approval is per offer, per unit, and single use
A recommendation is not permission to buy. Every checkout requires a fresh approval for one exact offer and one unit. The signed approval carries the merchant, variant, price, known total, and spending cap, and it can be used once. A price watch or a search does not grant buying permission.
NorthCinder rejects raw card details rather than storing or forwarding them. A supported automated checkout can use an opaque payment token, or NorthCinder can hand the buyer a cart link to finish in their own browser. Order outcomes stay local and attach only to the purchase they belong to. The README states that NorthCinder does not silently rewrite the buyer's profile and that its reminders only send notifications.
The practical consequence is that unattended purchasing is not the target. If your goal is an agent that buys things while you sleep, this design actively works against you. A native store connection must confirm the exact offer before checkout or an unattended watch, which means the adapter has to be able to verify the specific listing rather than a general product match.
Where it breaks down, and what to use instead
The clearest limitation is coverage. Built-in adapters exist for five store types, and the Amazon adapter is read-only comparison. Anything outside that set depends on the AI app's own browser or search tools feeding product facts into NorthCinder, which accepts product facts but not cookies, raw pages, passwords, or page instructions. The README also notes that the neutrality checks cover the offers NorthCinder received, not the completeness or truth of a store's catalog. A seller with a thin or misleading catalog is not something the ranking layer can fix.
The second limitation is the research qualification gap already quoted: no host and model combination is currently qualified for routine research. That is a self-declared ceiling on autonomy, and it means the provisional flag will be doing real work in normal operation.
A different approach is a marketplace-native agent, the pattern the README describes as an agent searching one catalog and steering the buyer toward that platform's checkout. The difference is not just breadth. A marketplace agent has the platform's inventory and payment rails behind it and can complete a purchase without a separate approval step, because the platform already holds the relationship. NorthCinder trades that convenience for a ranking it reruns locally, an audit log you own, and an approval that must be reissued for every purchase. If your priority is finishing a transaction with the least friction, the marketplace agent wins on that axis. If your priority is knowing why one offer outranked another and being able to inspect the rule, NorthCinder is built for exactly that.
Licence, maintenance, and what a version bump costs
NorthCinder is MIT licensed, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are preserved. This is not legal advice; if you redistribute it inside a product, read LICENSE and confirm your obligations.
The release history in the supplied material shows v0.1.2, v0.2.0, and v0.2.1, with the last two published on the same day, 2026-08-22. That cadence suggests active development and also means the surface is still moving at a pre-1.0 pace. The audit log format, the approval token contents, and the adapter interfaces are the parts most likely to shift between minor versions, since they sit on the trust boundary. The MCP entry printed by init is the other thing to re-check after an upgrade, because a changed transport or port behaviour would break a host connection silently.
Because there is no hosted service, there is no vendor upgrade path. You run npx northcinder init or rebuild from source with corepack pnpm build, and you own the result. That keeps the maintenance cost predictable in kind and unpredictable in timing: nothing breaks because someone else deployed, but nothing gets fixed for you either. The full release checks are documented in CONTRIBUTING.md, and bugs, questions, and vulnerabilities have separate channels, with vulnerabilities going through GitHub private vulnerability reporting rather than a public issue.
Editorial conclusion
Adopt NorthCinder if you want an MCP shopping server whose ranking rules and audit log live on your own machine and whose checkout path refuses to run without a fresh, single-use approval tied to one exact offer. Do not adopt it if you need full-market coverage or unattended purchasing, because store access is limited to the built-in adapters and the README states that no host and model combination is currently qualified for routine research. Before wiring it into anything real, run npx northcinder init, read docs/RANKING.md and docs/NEUTRALITY-AUDIT.md, then send one brief through your MCP host and check whether the result stays provisional when a source cannot confirm the exact product or seller.
Community notes