PRACTICAL FIELD GUIDE
Public reads and owner writes need a clear content model
Public-read and owner-write policies suit content that anyone may view but only its author should change. Every stored row in that public-read table must be appropriate for that audience.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Separate publishable content from private drafts or internal fields.
- Configure the intended independent read and write modes.
- Verify that an anonymous caller can read intended content but cannot modify it, and that another user cannot modify the author's row.
What this looks like
ILLUSTRATIVE EXAMPLE
A public recipe list can expose recipe text while each author manages their own entries through an app-user token.
A boundary to keep clear
A public-read policy is not automatically a published-status filter. Private drafts need a separate design.
MCPBackend context
MCPBackend row policies apply to anonymous callers and end-user tokens. Machine API keys bypass those row policies and are instead constrained by their own table permissions. Owner mode is based on the calling user's identity; it is not an organization-membership or arbitrary custom-policy engine.
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.