PRACTICAL FIELD GUIDE
Choose a primary key before wiring record URLs
The primary key determines how an individual record is addressed through the generated API. Decide its meaning before application code starts treating a display field or array position as the identifier.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inspect the table's actual primary key in the schema.
- Use the returned key value when constructing record requests, keeping it distinct from the row's position in a list.
- Test fetching and updating a record after its display name changes.
What this looks like
ILLUSTRATIVE EXAMPLE
A task title changes from Draft to Published while its numeric ID remains stable. The record URL should continue using the ID.
A boundary to keep clear
Do not assume every table's primary key is an automatically generated integer. Explicit schemas can define a different key.
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.