Revel Systems MCP – Invoice-to-COGS Automation for Claude Desktop
A small, purpose-built MCP server that lets an AI agent running in Claude Desktop read and update product costs and retail prices in a Revel Systems point-of-sale account. The client is a beauty-supply retailer whose supplier costs used to be stable for years at a time; recent tariff volatility now forces cost updates several times a month, which became tedious and error-prone to do by hand through the Revel UI.
The intended workflow is end-to-end: supplier invoices arrive by email, Claude extracts the line items and new cost prices, and this MCP pushes the updates into Revel in a single batch. The model drives the whole thing; this project is the bridge between the model and the POS.


I deliberately kept the tool surface narrow, five tools covering product lookup and batch price updates, rather than wrapping the full Revel REST API. A narrower surface is easier to test, easier for the model to use correctly, and (most importantly here) safer against accidental writes to fields that nobody asked for. Anyone who needs something outside the happy path can call the Revel REST API directly with curl; the MCP is not trying to be a general-purpose client.
Under the hood it is a TypeScript server built on Anthropic’s MCP SDK, talking to Revel over their legacy API key auth. Because there was no live sandbox at the start of the build, I wrote a FastAPI mock server that mirrored the relevant parts of Revel’s Tastypie-style REST API, plus an integration test suite in Python that drives the MCP server via stdin/stdout and asserts the raw HTTP contract (headers, query params, PATCH bodies) against the mock. That let me validate the whole stack against the Revel documentation without waiting for credentials, and it now keeps CI fast and offline. When live credentials did arrive, only a handful of contract items needed adjusting — for instance, a data-integrity quirk in the client’s tenant that makes some products fail on PATCH for unrelated reasons, which the server now detects and translates into an actionable error.

Updates are safety-oriented by default. The installer exposes a “dry run” checkbox that makes every write tool simulate its result instead of hitting the API, so the client can install the extension, let the agent run through a realistic invoice, and verify nothing actually changed before flipping the switch for real.

