Guide
Govern MCP access with a discovery-and-invocation test matrix
A client can list a support tool. The integration team treats that as evidence that access is configured. Then the first real invocation is refused.
A tool listing shows what the client can discover. A tool call asks to do the work. Test both: seeing a search tool in the list doesn't prove the agent can use it, and a successful call doesn't prove unwanted calls are blocked.
Pick one useful call and one call that must fail
Consider a hypothetical support agent using a gateway that exposes ticket search but not ticket deletion. The objective is narrow: approved callers can search through the selected gateway, while other callers and operations are refused.
The authorization foundation explains which decisions belong at the credential, call, and business boundaries. Here, check that the agent can search tickets through the intended gateway but cannot delete them.
Dome's Tool Gateway serves Model Context Protocol (MCP) through a named gateway endpoint. Discovery is filtered by gateway membership and rules. It is exempt from the gateway access grant required for invocation. Tool calls require addressability, admission, and rule authorization.
Change one condition at a time to find out which check is responsible for each result.
Test listing and calling separately
The following is a proposed acceptance test, not a report of executed results. Run it with synthetic data and record the actual evidence for each row.
| Case | Condition under test | Expected finding |
|---|---|---|
| Search tool is outside the addressed gateway | Membership | It is not discoverable there and cannot be invoked through that gateway |
| Search tool is a member, but discovery rules exclude it | Discovery authorization | It does not appear in the caller's listing |
| Caller can discover search but lacks invocation admission | gateway access | Listing alone does not establish a usable call path |
| Caller is admitted, but the search call lacks a permit | Invocation authorization | The call is refused |
| Caller is admitted and the intended search is permitted | Positive control | The request can proceed to the backend, where execution must be checked |
| Caller changes the requested operation to deletion | Neighboring forbidden operation | The intended boundary continues to refuse the operation |
| Client uses an old direct endpoint and credential | Route coverage | Document whether that alternate path remains possible and whether it is an approved exception |
Do not change several conditions between tests if the result needs to identify a specific control. For example, a wrong gateway and a missing permit can both produce refusal. That does not tell you which configuration works.
Retain the caller identity, addressed gateway, tool, expected decision, observed decision, and corresponding audit reference. For the positive control, include backend evidence; a permitted request that fails upstream has not established a functioning search workflow.
Test the path the deployed client uses
Use the gateway's returned MCP URL and the documented Streamable HTTP transport. Testing a local script against the correct endpoint does not establish that the production application's configuration points there.
Inspect the deployed endpoint and credential references, not their secret values. Include any emergency or fallback configuration the application can choose. If it still holds a direct backend credential, the final row of the matrix remains an operational question.
A gateway provides controls on traffic sent through it. Coverage requires an explicit decision about other paths: remove them, restrict them, or retain them as named exceptions with their own controls.
Can the caller search another customer's tickets?
The search tool may accept a customer identifier. For this integration, include one cross-customer request and verify that the system with authoritative ownership information refuses it.
A search that works on the wrong customer's tickets is still a failed test. Check ownership in the system that holds the customer records.
If request or response guards are part of the chosen design, add a specific content case and expected behavior. Do not treat an unconfigured control as something the gateway is implicitly providing.
Compare candidates using the same cases
If you're choosing a gateway, run the matrix against each candidate—including your existing infrastructure. Use the same read, constrained write, and refused operation. Also check credential isolation, any required user verification, content handling, and recovery after unavailable policy. Mark each required check demonstrated, partial, or not demonstrated.
A high overall score shouldn't offset a failed requirement. If the workflow requires a verified person or a protected field, a candidate must pass that test before it can be approved for the workflow.
Record exactly what you tested
Record the agent, gateway, operations, and route you tested. Mark each case passed, failed, or not run, and keep any direct-access exceptions visible.
For the support integration, approval should mean that the search path works and its neighboring forbidden cases fail for understood reasons. Use the Tool Gateway guide to configure the path, then keep this matrix with the application's acceptance evidence.