Explainer
Choose a filter or validator for a tool content contract
Suppose a routing tool returns an employee's email address but leaves out their ID. You want to remove the email. You also need to reject a result that can't identify the employee.
Those cases need different controls. A filter can transform or withhold content. A validator checks configured structural conditions and blocks when they fail. Removing the email doesn't repair the missing ID.
The table includes controls for Model Context Protocol (MCP) tool responses. Check the supported connection and direction before assigning a guard.
Should you change the content or reject it?
| Requirement | Starting mechanism | Expected result |
|---|---|---|
| Replace a protected field value | JSON filter with redaction | Field remains with a redaction sentinel |
| Remove a key entirely | JSON filter with omission | Key/value absent |
| Withhold matching content | Blocking filter | Whole message withheld on that match |
| Require a request field | Tool-request validator | Missing required path blocks |
| Bound request payload size | Tool-request validator | Oversized request blocks |
| Require a supported structured MCP response | Tool-response validator | Missing required shape blocks |
| Authorize a business action for a caller | rules | Allow/deny decision about authority, not a structural content repair |
Dome documents filter kinds and validator conditions in the Guard reference. Use the supported conditions as written; do not present a required-path check as a general schema validator or a test of business truth.
Review a response contract
In this example, the application needs an employee ID and team to route work. It doesn't need contact details.
A filter can redact the email. It should not fabricate an employee ID when the server omitted one. A validator can require the paths the application depends on. It does not establish that the team is correct in the business system.
The resulting contract has two independent expectations:
| Test response | filter expectation | validator expectation |
|---|---|---|
| Required fields plus email | Remove/redact protected contact value | Required structure passes |
| Email present, employee ID missing | Handle the protected value as configured | Reject missing required structure |
| Required fields with a wrong real-world team | No automatic semantic correction | Presence alone cannot prove correctness |
| Oversized payload under a configured size rule | No assumption that redaction repairs it | Enforce the supported size condition |
| Required structured content absent | No invented structured record | Apply the configured MCP response requirement |
These are illustrative test expectations, not a promise about evaluation order between every configured control. Inspect the actual connection and direction and test the resulting composition.
Check the connection and direction
Filters run as an ordered chain on a connection/direction. Validators attach as a set whose assigned conditions must pass. Model connections accept text filters; tool connections use JSON filters. The currently documented response validator path is MCP-only.
That distinction affects maintenance. Replacing a filter chain changes the complete ordered list for that slot. Attaching a validator adds a structural requirement, not another rewrite step. Save the assignment state along with the control version when reviewing a change.
The Guards concept describes the content path and fail-closed behavior. Configuration that cannot be evaluated should not silently turn inspection off.
Test what your application receives
Inspect what the application does with a redacted value, an omitted field, and a withheld response. Those outcomes are not interchangeable. If your application tries to send mail to [REDACTED], it needs to handle that response differently.
Use the response redaction fixture for value-level regression. Keep authoritative record checks in the backend or trusted resolver; neither a matching pattern nor a present field proves the fact it names.
For each requirement, write down whether it changes a value, blocks a match, or rejects missing structure. Then test the application's next step: does it continue with safe data, ask for a corrected result, or stop?