Data minimization risk

What mcp-scan saw

This runs only after data-controls-pii fired. The scanner then counted the keys under each tool's inputSchema.properties and reported every tool with more than ten. It counts declared properties, with no distinction between required and optional.

Why it fires

A wide input schema is a wide collection surface: every declared property is something the model can be persuaded to fill in, and on a server already flagged as handling personal data that means more fields available to over-collect. The threshold is a flat calibration constant in the source, not a computed one.

When this is a false positive

• Optional filters count the same as required fields. A search tool with twelve optional narrowing parameters collects less per call than a three-field tool that requires all three.
• A schema generated from an upstream OpenAPI spec inherits every field the API declares, whether the tool uses it or not.
• The gate rule may have been a keyword match. If data-controls-pii fired on 'email' in a tool name, the property count is about nothing.
• Nested objects count as one property each, so a tool with three properties that are each large objects passes while a flat tool with eleven scalars fails.

How to fix it

1. Read the data-controls-pii finding first to check whether real personal data is involved.
2. Open the tool named in the finding and count how many properties are actually required.
3. Drop properties the tool never reads. Schemas copied from an upstream spec usually carry several.
4. Group related optional parameters into a single nested object, which is both clearer for the model and drops the top-level count.
5. To suppress the whole family for one server, add its config key to .mcp-scan-ignore.