Skip to main content
Customer guide

MCP and agent tools

Scope local guard use to explicitly routed tools and verify the upstream effect.

For: Agent administrator, Developer, Security policy owner

Before you begin

Identify the agent client, exact tool server, allowed operations and workstation owner. Obtain permission to change the client’s local server configuration; test with a harmless tool effect.

  1. Choose a synthetic denied call and a safe allowed call.
  2. Check the current supported MCP client and server profile.

Supported scope and current status

Approves or refuses tool calls routed through the RedactWall MCP guard before the upstream server runs, and checks results before the model receives them. Calls made through another route are outside the guard.

  1. Read /integrations/mcp-clients for the route boundary.
  2. Do not infer all agent activity from a guarded server list.

Compare this path with the published coverage table and the coverage guide.

Set up the path

With the client administrator, register the approved server through the guard using release-specific instructions. Assign a policy that names the tool and effect scope rather than a blanket agent approval.

  1. Confirm the client launches the guarded command.
  2. Check that a direct server entry has not remained active by accident.

Use the workflow

Run the safe allowed call, then the denied synthetic call. Observe both the client-facing result and whether the upstream tool actually performed an effect.

  1. Record the tool name, effect scope and policy revision.
  2. Use a result-bearing call to test the return path separately.

Verify the result

A denied call must produce no upstream effect, while an allowed call has a scoped, attributable effect and an inspected result. A model response alone is not an independent readback.

  1. Check the upstream test target or its audit trail.
  2. Match the guard decision to the exact call and return result.

Coverage references: 5 requirements, 0 currently passed

This guide is bound to 5 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.

See the public verification overview and the documentation coverage guide.

Denials and recovery

If the client starts a server directly, the guard is bypassed. If the handshake, version or policy fails, stop the agent session and restore the last approved client configuration.

  1. Remove the unguarded entry and restart the client.
  2. Repeat the safe and denied test after a fresh configuration read.

For customer-side next steps, read Recovery and support.

Billing and integration handoffs

Agent protection depends on local client configuration and the chosen tool server. A workspace or device license does not automatically govern tools started through other routes.

  1. Coordinate the client and server owner handoffs.
  2. Check /pricing for the current commercial scope before wider deployment.

Limits to keep in view

The proposed first guided pilot excludes MCP tool-call inspection. The current public integration page describes a workstation path, not a universal guard for every agent, server or protocol version.

  1. Seek release-specific conformance proof.
  2. List direct and unsupported tool routes as gaps.

Review the current Disclosures before relying on a capability.