PRACTICAL FIELD GUIDE
Store money with an explicit unit and currency
Money fields need a unit and currency contract, not just a numeric type. Integer minor units can avoid floating-point surprises for amounts that use a fixed supported scale.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Choose a documented amount unit and store the currency beside it.
- Convert user input using the currency's intended scale and validation rules.
- Test totals, rounding and display conversion at the application boundary.
What this looks like
ILLUSTRATIVE EXAMPLE
An amount of 1299 represents 12.99 only under the chosen two-decimal currency convention. Without that convention the stored number is ambiguous.
A boundary to keep clear
Not every currency uses two decimal places. Do not apply one scaling rule universally or treat a database field as a payment processor.
MCPBackend context
MCPBackend stores each project's data in SQLite and exposes supported tables through generated REST endpoints. Use the schema tools and dashboard for supported changes. The design examples here are patterns to adapt, not claims that the API exposes every SQLite feature or arbitrary SQL.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.