PRACTICAL FIELD GUIDE
Why tables starting with an underscore are reserved
MCPBackend reserves underscore-prefixed tables for internal data such as application users. Public app data should live in ordinary supported tables rather than trying to expose or repurpose system tables.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Check the proposed name against the platform's naming rules.
- Create a separate application profile or domain table with only the fields your app needs.
- Link application records through appropriate identifiers and policies without accessing password storage.
What this looks like
ILLUSTRATIVE EXAMPLE
An app needs a display name for each user. A profiles table can hold that data without exposing the reserved authentication table.
A boundary to keep clear
Do not treat reserved user storage as an ordinary CRUD endpoint. Keeping password hashes outside application reads is an intentional boundary.
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.