PII privacy data anonymization and synthetic data masker
This server has a single tool 'mask_pii' with severe deficiencies across all dimensions. The tool has a hardcoded mock implementation that does not actually mask PII, lacks meaningful descriptions, and exposes a minimal schema with no parameter documentation. The codebase shows no evidence of a functional MCP server framework, no transport layer, no server initialization, no tool registration mechanism visible. The tool appears to be a Python class method stub rather than a properly registered MCP tool.
Tool has no description field. The tool definition shows no description text whatsoever, making it impossible for an LLM to understand when or why to invoke this tool.
Input parameter 'text' lacks a description. The schema shows {"type":"string","description":null}, which violates the requirement that every parameter must have a non-empty description explaining what it controls.
Output schema is not documented in the source code. There is no declaration of the return type structure, fields, or typing for the 'masked_text' response field. LLMs cannot plan downstream operations without knowing what they will receive.
Tool implementation is a mock/stub. The client.py shows hardcoded output ('Contact [NAME] at [EMAIL] SSN [REDACTED]') that does not actually process the input 'text' parameter. This is not a functional tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 20 | 2026-07-28+ | v2 |
No MCP server framework detected. The source shows a Python class and example usage, but no evidence of MCP protocol implementation (no stdio/HTTP transport, no tool registration, no MCP message handling).
No error handling or input validation. The tool does not validate the 'text' parameter (e.g., null checks, length bounds) or provide recovery guidance if masking fails.
No mechanism to specify PII types or masking strategy. A production PII masking tool should accept parameters like 'pii_types' (enum: ssn, email, phone, name, etc.) and 'masking_style' (redact, replace, hash). The current single-parameter design cannot handle diverse masking needs.