Trust & authority

Routing a device, inspecting an HTTPS connection and giving an agent access to evidence are three different decisions. Start with the one your question requires. To find out whether a phone contacted a host, for example, you may need only routing. To find out whether a price arrived as a string, you need the response. You don’t need to share that response with an agent to inspect it yourself.

Decide on the device: where should requests go?

Follow the platform setup guide for the app making the request. Note its previous proxy settings. Make one fresh request and match the host and time on the Mac. The listener being on doesn’t mean this device uses it, and traffic from Safari doesn’t establish that another app took the same route.

Decide on the test host: do you need the contents?

For a service you are authorized to inspect, review the development certificate and trust it on the target used for the test. Look at the resulting session: an inspected response can expose headers and bodies; a tunnel cannot. Some apps reject inspection even when the operating system trusts the certificate. Use the evidence you can observe or a test client you control. Don’t bypass the app’s certificate checks.

Decide on the Mac: what may a client read or change?

Enroll the intended MCP client and begin with metadata. A status and time may answer the question without disclosing cookies, URLs with identifiers, or a customer payload. Listing a tool doesn’t grant access. If a client proposes a change, review the specific target and effect on the Mac. Requesting a change, approving it, and seeing it affect a matching request are distinct events.

Close out the test

Stop temporary effects and verify an ordinary request. Review grants separately from routing: disconnecting an agent doesn’t remove device trust, and stopping capture doesn’t undo a phone’s Wi-Fi setting. Restore the target, remove temporary trust you added, and review any export before sharing it.