PRACTICAL FIELD GUIDE
Plan a public form without publishing submissions
A public submission form needs write access without exposing its collected records. Separate the submission route from the privileged review workflow.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Define exactly which fields anonymous callers may submit and validate them in the application.
- Choose an intentionally public write path or a trusted server with a narrowly scoped key.
- Keep reads private and test that anonymous list and direct-record requests do not reveal submissions.
What this looks like
ILLUSTRATIVE EXAMPLE
Visitors submit a contact message, while a server-side review tool reads it with appropriate machine permissions.
A boundary to keep clear
A public write policy is not anti-abuse protection. Rate controls, validation and spam handling require an additional 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.