PRACTICAL FIELD GUIDE
Make your first MCPBackend REST request
A first request should verify the actual project URL, table name and caller type with the smallest useful read. This separates connection problems from later form or mutation logic.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Retrieve the project's generated API contract and choose an existing table.
- Send a list request with a small limit and the intended end-user token, server key or public policy.
- Check status, JSON data and metadata before building the rest of the integration.
What this looks like
ILLUSTRATIVE EXAMPLE
A read returns an empty data array with a successful status. The connection works even though this caller has no visible records yet.
A boundary to keep clear
Do not create a broad machine key simply to bypass a policy problem in a browser app.
MCPBackend context
Use get_project_api or the dashboard's generated OpenAPI contract for your project's exact data-plane routes. Machine keys and end-user tokens have different access models. Treat error status and JSON code together, keep credentials out of URLs, and test against disposable records before changing real data.
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.