PRACTICAL FIELD GUIDE
Use supported REST filter operators
MCPBackend filter syntax supports defined operators rather than arbitrary SQL expressions. Build query parameters from the generated contract and known columns.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Choose a supported field and operator for the intended comparison.
- Encode the query parameters with a URL builder rather than concatenating untrusted input.
- Test matching, nonmatching and invalid filters and handle a 400 response visibly.
What this looks like
ILLUSTRATIVE EXAMPLE
A status equality filter and a date comparison can form a supported request, while a guessed SQL fragment is not a filter API.
A boundary to keep clear
Do not assume operators from another backend are accepted. Unknown columns and operators should be treated as contract errors.
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.