Guide
Return only the tool fields an agent needs
A Model Context Protocol (MCP) directory tool returns the employee's team and contact details. The agent needs the team to route a request, but it does not need the personal email address.
Write down the response the agent should receive before configuring a filter. Then you'll have something concrete to compare with the result.
Start with an input and an allowed output
This is illustrative synthetic data, not a captured production record.
{
"employee": {
"id": "test-104",
"team": "Support",
"email": "person@example.test"
},
"request": {"category": "account-access"}
}For a redaction requirement, the expected returned shape is:
{
"employee": {
"id": "test-104",
"team": "Support",
"email": "[REDACTED]"
},
"request": {"category": "account-access"}
}Check that the team and request category survive too. A response that loses every field may avoid disclosure but still fail the application's contract.
If the consumer should not receive the email key at all, choose omission instead of redaction. If the entire response must be withheld when the condition matches, choose blocking. Those are different outcomes.
Choose which email fields to match
Dome's JSON filters support exact field paths and a leading recursive prefix. The guard reference defines the supported dialect; do not assume arbitrary JSONPath syntax.
For the example, an exact employee.email path targets the reviewed field. A recursive **.email path is appropriate only if every field named email should receive the same treatment. That is a data-owner decision. A broad matcher can alter a field that happens to share a name but serves a different purpose.
The connection and direction matter as much as the matcher. A response filter changes returned content before the agent receives it. A request filter acts on outgoing arguments. Configuring the right matcher on the wrong direction does not satisfy the fixture.
Build a small regression set
| Fixture variation | Expected check |
|---|---|
| Baseline object | Protected value is redacted; required nonprotected fields survive |
| Same field nested differently | Behavior matches the chosen exact or recursive path |
| Array of employee objects | Each intended occurrence is handled |
| MCP structured content plus a JSON-bearing text mirror | No protected copy remains in an inspected representation |
| Field absent | No invented value; application still handles the result |
| Similar nonprotected field | No unintended modification |
| Blocking condition | The caller receives the defined safe refusal, not a partial leaked payload |
| Assigned guard cannot evaluate | The protected connection/direction fails closed |
The matrix is a proposed test set. Run it against the actual integration before claiming the configuration protects those shapes.
Dome documents multiple tool-result representations, including structured content and embedded JSON. That is a reason to test the server's real output forms, not to assume every copy is identical.
Check the returned data and the audit record
The guards concept distinguishes filter actions from the enclosing call verdict. A redaction event describes an action on content; it is not itself proof that the business operation failed. A response block also does not undo an upstream write.
Retain the synthetic fixture, expected result, filter version/assignment, and audit identifiers. Keep real personal data out of the review packet.
If the application instead requires a field to be present, see content filtering vs. schema validation. If the operation should never be attempted, use rules rather than expecting response redaction to make the action acceptable.
Compare the actual response with your expected fixture. The team and category should still be usable, and the email should be handled as agreed—in every response shape you've tested.