Skip to main content
Glama
fairquery

fairquery-llm-data-guard

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Detect / redact PII and secrets before LLM use

guard_text
Read-onlyIdempotent

Scan and redact PII and secrets in text or public documents before LLM use, then restore placeholders to return original values.

Instructions

WHAT: Scan text documents (or public document URLs: txt/md/json/csv/HTML/PDF) for PII (emails, phones, US SSNs, Luhn-valid cards, IBANs, UK NINOs, IPs, optional person names/addresses) and secrets (AWS/GitHub/Slack/Stripe/OpenAI/... keys, JWTs, private keys, URL credentials, high-entropy key=value). mode="redact" returns sanitized text; mode="restore" puts originals back into LLM output using a placeholder map. WHEN TO USE: before sending prompts, tickets, logs or files to an LLM or third party; to audit text for leaked credentials; to de-anonymize an LLM answer after a placeholder redaction. WHEN NOT TO USE: to see which entity types exist or pick entityTypes, call list_detectors (free, local). Not for binary files/images (PDF text layer only, no OCR) or for validating whether an email is deliverable. COST: paid. Runs Apify Actor fairquery/llm-data-guard-pii-secrets with your APIFY_TOKEN; pay-per-event billed per document processed and per finding (error rows free). Typical run a few seconds. RETURNS: {count, items}. One type="document" row per input with id, source, chars, truncated, mode, finding_count, counts_by_type, risk_level, findings[] (type, offsets, masked preview; raw values are not returned), output_text (redact/restore modes), placeholder_map (only if returnPlaceholderMap=true); or type="error" rows with code/message. EXAMPLE: {"texts":["Mail jane@acme.com, key AKIAIOSFODNN7EXAMPLE"],"mode":"redact","redactionStyle":"placeholder"} -> output_text with the email replaced by [EMAIL_1] and the key by a placeholder; findings lists EMAIL and AWS_ACCESS_KEY. Provide texts and/or documentUrls (at least one).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo"detect" = report findings only; "redact" (default) = also return output_text with values replaced; "restore" = replace placeholders in texts with originals from placeholderMap.
textsNoDocuments to scan, one string per document (prompt, chat message, ticket, log line, file content). Example: ["Hi, I am Jane (jane.doe@acme.com)"]. Optional if documentUrls is given.
allowListNoExact values that are never flagged, e.g. ["support@yourcompany.com"]. Default [].
detectNamesNoDefault false. Detect person names with English NER (lower precision, slightly slower).
entityTypesNoOnly report these entity types, e.g. ["EMAIL","CREDIT_CARD","AWS_ACCESS_KEY"]. Omit/empty = all enabled detectors. Valid names: see list_detectors.
entropyScanNoDefault false. Also flag unlabeled random-looking tokens of 20+ chars (catches unknown key formats; may flag hashes/IDs).
documentUrlsNoPublic http(s) URLs of txt, md, json, csv, HTML or PDF files (max 10 MB each; PDFs text layer only). Example: ["https://example.com/report.pdf"]. Optional if texts is given.
placeholderMapNoOnly for mode="restore": map of placeholder -> original value returned by a previous redact call, e.g. {"[EMAIL_1]":"jane@acme.com"}. Default {}.
redactionStyleNoUsed in redact mode. "placeholder" (default) = [EMAIL_1], reversible via placeholder map; "mask" = j***@a***.com / **** 1111; "hash" = [EMAIL:3f2a9c0d1b7e] salted sha256 prefix.
detectAddressesNoDefault false. Detect street addresses (English formats) and NER place names.
defaultPhoneRegionNoISO 3166-1 alpha-2 country code used to parse phone numbers written without +country prefix, e.g. "US" (default), "DE", "GB".
returnPlaceholderMapNoDefault false. If true, each row includes placeholder_map {"[EMAIL_1]":"jane@acme.com"} needed for restore mode. Contains the original sensitive values.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of rows in items
itemsYesDataset rows: type=document (findings, risk_level, output_text) or type=error

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the paid/pay-per-event cost model, the backing Actor and required APIFY_TOKEN, that raw sensitive values are not returned, that PDFs are text-layer only (no OCR), and the exact {count, items} shape including error rows. Annotations already cover safety, and the description adds rich operational context on top.

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?

Front-loaded with labeled WHAT / WHEN TO USE / WHEN NOT TO USE / COST / RETURNS / EXAMPLE sections. Despite its length, every section earns its place given 12 parameters, a paid external Actor, and three operating modes.

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?

Covers the at-least-one-of constraint (texts and/or documentUrls), unsupported inputs, cost, auth, and return shape even though an output schema exists. For a complex multi-mode tool with an external dependency, nothing an agent needs to invoke it correctly 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 the baseline is 3; the description earns extra by explaining mode semantics, illustrating redactionStyle output, and pointing entityTypes validation at list_detectors. It adds meaningful interpretation (e.g. returnPlaceholderMap contains original sensitive values) rather than restating the schema.

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

Purpose5/5

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

States specific verbs (scan, redact, restore) and resources (text documents, public document URLs) and enumerates exactly what is detected (PII types, secrets). It distinguishes its three modes and names the sibling list_detectors, so an agent can separate it from alternatives without opening a schema.

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

Usage Guidelines5/5

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

Explicit WHEN TO USE (before sending prompts/tickets/logs to an LLM, auditing for leaked credentials, de-anonymizing output) and WHEN NOT TO USE (entity discovery → list_detectors; no binary/image support; not email-deliverability validation). Both conditions and the alternative tool are named, leaving nothing to inference.

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

Deploy Server

Other Tools