IA-QA — 152 QA & Dev Tools for AI Agents

redact_pii

Read-onlyIdempotent

Automatically detect and redact Personally Identifiable Information (PII) from text. Replaces emails, phone numbers, SSNs, IBANs, credit cards, IP addresses, and JWT tokens with [REDACTED_TYPE] placeholders. Safe to use before logging or sending to an LLM.

Input Schema

Name	Required	Description
`input`	Yes	Text to redact PII from
`types`	No	Comma-separated types to redact (default: all). Options: email, phone, ssn, iban, credit_card, ip_address, jwt
`marker`	No	Custom replacement marker (default: "REDACTED"). Result: [REDACTED_EMAIL]

Output Schema

Name	Required	Description	Default
`clean`	No
`pii_found`	No
`replacements`	No
`redacted_text`	No
`total_redactions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026
- addedInput schema / examples
```
Added value: +[
+  {
+    "input": "order #12345678"
+  }
+]
```

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / types / description

Previous value: -"Comma-separated types to redact (default: all). Options: email, phone, ssn, credit_card, ip_address, jwt"New value: +"Comma-separated types to redact (default: all). Options: email, phone, ssn, iban, credit_card, ip_address, jwt"

Changed1 schema field changedJun 21, 2026

addedOutput schema / properties

Added value: +{
+  "clean": {
+    "type": "boolean"
+  },
+  "pii_found": {},
+  "redacted_text": {},
+  "replacements": {},
+  "total_redactions": {}
+}

Changed1 schema field changedJun 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedMay 26, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description contributes meaningfully beyond the annotations: it discloses which data classes are replaced and the exact placeholder format ([REDACTED_TYPE]), which tells the agent the output is transformed in a predictable way. The readOnly/idempotent/non-destructive safety profile is already covered by annotations, and an output schema exists, so return shape is not the description's burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with zero filler: the core action comes first, then the enumerated coverage, then the safety/usage note. Every sentence carries information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given rich annotations, an output schema, and 100% parameter coverage, the description fills the remaining gaps: what is redacted, how it is marked, and why/when to call it. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real value by listing the redactable types (email, phone, ssn, iban, credit_card, ip_address, jwt) in the same vocabulary as the 'types' parameter, and by showing the marker output pattern ('[REDACTED_TYPE]') that clarifies the 'marker' parameter's effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair and resource ('detect and redact PII from text') and enumerates the exact PII classes handled, so an agent knows precisely what it does. It stops short of explicitly distinguishing itself from sibling tools like detect_secrets or secret_scan, which also touch sensitive strings, so sibling differentiation is implied (redaction vs detection) rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Safe to use before logging or sending to an LLM' gives a concrete usage context that tells the agent when this tool is appropriate. It does not name an alternative tool or state when-not-to-use conditions, so it is clear context without explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All IA-QA — 152 QA & Dev Tools for AI Agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.