Consent gap

What mcp-scan saw

This runs only after data-controls-pii fired. The scanner then searched the lowercased serialized server config for consent, opt-in, 'opt in', agree, or 'privacy policy'. None present means this finding. The search is substring matching over the whole JSON, so an env key name counts as evidence.

Why it fires

It is the cheapest available check for whether anyone thought about consent: a config that processes personal data and contains no consent vocabulary anywhere usually means no consent mechanism exists. It cannot verify a mechanism, only its absence from the text, which is why it sits at MEDIUM rather than higher.

When this is a false positive

• Consent is collected upstream, in the product's own signup flow or in a data processing agreement, and has no reason to appear in an MCP client config.
• The gate rule was wrong. If data-controls-pii fired on the word 'email' in a tool name, there is no personal data to consent to, and this finding inherits that error.
• The server is a read-only client of a system where consent is already handled, for example a CRM whose records were collected under the CRM's own terms.

How to fix it

1. Read the data-controls-pii finding first. It lists the detected categories and tells you whether this gap is about real data.
2. If the gate was a keyword hit on a description, fix that rule and this one clears with it.
3. If the server does process personal data, confirm where consent is captured and record it in the server's documentation.
4. Adding a PRIVACY_POLICY_URL env var to the server config satisfies the substring search and gives the config a pointer to the actual policy.
5. To suppress the whole data-controls family for one server, add its config key to .mcp-scan-ignore.