Recursively sanitize JSON objects and arrays by tokenizing, redacting, or masking PII and sensitive keys before sending data to LLMs while preserving schema types.
Recursively scrub PII and sensitive keys (password, secret, api_key, ssn) in a JSON object or array while preserving schema types.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | JSON object or array to sanitize | |
| mode | No | tokenize |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses recursion, the specific key set scrubbed, and schema-type preservation, but omits critical behavior: whether the input is mutated in place or a sanitized copy is returned, and whether 'tokenize' output is reversible via rehydrate_text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the action and scope front-loaded, the key list inline, and the type-preservation guarantee last. Nothing is wasted or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations and no output schema, the description should at minimum clarify return shape and mutation semantics and the meaning of the mode enum. It covers scope and target keys well but leaves these operative gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'data' is documented but 'mode' has only an enum and default with no description. The description never explains what tokenize vs redact vs mask actually produce, which is the single most consequential choice an agent must make when calling this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('scrub'), a precise resource ('JSON object or array'), and enumerates target keys (password, secret, api_key, ssn), plus recursive scope and type preservation. It implicitly distinguishes itself from scrub_text by operating on structured JSON, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the JSON-object-or-array scope hints at when to pick this over scrub_text, but the description never states when to use it versus scrub_text or rehydrate_text, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.