Skip to main content
Glama

Fairquery Agent Trust & Data Safety

Redact PII and secrets (free, on this Worker)

pii_redact_text
Read-onlyIdempotent

WHAT: Return sanitized copies of texts with every local PII/secret finding replaced (placeholder [EMAIL_1], mask, or salted hash). WHEN: Right before sending user data to an LLM/third party. Use returnPlaceholderMap=true if you need to restore originals in the LLM answer later. WHEN NOT: For a findings report only use pii_scan_text. For names/addresses NER, URLs or PDFs use pii_guard_documents (paid). COST: Free; no token. RETURNS: One "redacted_document" row per text with output_text; meta.placeholder_map only when requested. Errors: INPUT_TOO_LARGE. BEHAVIOR: Same input gives the same output except redactionStyle "hash" (random per-call salt). Runs on this Fairquery-hosted Worker (Cloudflare), not on the caller's machine; inputs leave the client. This Worker's code is designed not to store inputs, results, or an Apify token. No further network call; texts are not forwarded. Milliseconds. PARAMETERS: texts: one element per document, 500,000 chars in total; the same value gets the same placeholder in every document of one call ([EMAIL_1] everywhere), but numbering restarts on each call. redactionStyle: "placeholder" is the only reversible style; "mask" keeps a few characters for human review; "hash" output differs between calls (random salt), so do not compare hashes across calls. returnPlaceholderMap: only has an effect with redactionStyle="placeholder" (ignored for mask/hash); the map in meta.placeholder_map holds the ORIGINAL values, so keep it out of the LLM prompt and restore answers with pii_restore_text (free, on this Worker). entityTypes / allowList / entropyScan / defaultPhoneRegion: identical semantics to pii_scan_text (filter after detection, whole-value case-insensitive allow-list). limit/offset page whole documents (one item per text, default 10 per page), not findings. EXAMPLE: {"texts":["Call +1 415 555 0100 or mail jane@acme.com"]} -> output_text "Call [PHONE_1] or mail [EMAIL_1]".

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size: items to return, integer 1-50 (default 10). Example: 10
textsYesRequired. 1-50 documents (prompt, chat message, log, file content), each <= 200,000 chars, total <= 500,000 chars. Example: ["Mail jane@acme.com, key AKIAIOSFODNN7EXAMPLE"]
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
allowListNoOptional, default [] (nothing exempt). 0-500 exact values (<= 500 chars each) that are never flagged; whole-value, case-insensitive match, not substring. Example: ["support@yourco.com","192.0.2.1"]
entityTypesNoOptional, default omitted = every free-tool detector (pii_list_detectors rows with local:true). 0-40 detector type names (<= 40 chars, case-insensitive), e.g. ["EMAIL","CREDIT_CARD","AWS_ACCESS_KEY"]. Valid values: the "type" field of those rows; unknown names match nothing (no error)
entropyScanNoOptional boolean, default false. true also flags unlabeled random-looking tokens of 20-200 chars as HIGH_ENTROPY_STRING (catches unknown key formats; may flag hashes/UUIDs). Example: true
redactionStyleNoOptional, one of "placeholder" | "mask" | "hash", default "placeholder". "placeholder" = [EMAIL_1] (reversible); "mask" = j***@a***.com, **** **** **** 1111; "hash" = [EMAIL:3f2a9c0d1b7e] (salted sha256 prefix, random per-call salt). Example: "mask"placeholder
defaultPhoneRegionNoOptional, default "US". ISO 3166-1 alpha-2 code (2 letters, pattern ^[A-Za-z]{2}$, case-insensitive) used only for phone numbers written without a +country prefix. Examples: "US", "DE", "GB"US
returnPlaceholderMapNoOptional boolean, default false. true (placeholder style only) adds meta.placeholder_map {"[EMAIL_1]":"jane@acme.com"} containing the ORIGINAL sensitive values. Example: true

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (summary counts, cost notes, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Goes well past the annotations: discloses determinism (identical output except hash style with per-call random salt), where computation happens (Fairquery-hosted Cloudflare Worker, inputs leave the client), the no-storage/no-forwarding guarantee, latency, and the INPUT_TOO_LARGE error. One small tension: idempotentHint=true while hash output varies between calls — the description explains this, so it is disambiguation rather than a contradiction, but it slightly undercuts the annotation's guarantee.

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

Conciseness4/5

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

Front-loaded with labeled sections (WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE), so an agent can stop reading early. It is long for a description, but nearly every line carries decision-relevant information; the COST and hosting lines are the least essential.

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?

Nine parameters, an enum, and an output schema are all accounted for: return shape, placeholder_map location, error case, and the restore path via pii_restore_text are documented. Nothing an agent needs to call this correctly on the first try is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds non-obvious semantics: placeholder numbering is stable across documents within a call but restarts per call, hash values must not be compared across calls, returnPlaceholderMap is silently ignored for mask/hash and contains ORIGINAL values that must be kept out of the prompt, and limit/offset page documents not findings.

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?

Opens with an explicit verb+resource+output: 'Return sanitized copies of texts with every local PII/secret finding replaced', and names the exact placeholder/mask/hash forms. It is unambiguously distinguishable from pii_scan_text (findings report) and pii_guard_documents (NER/URLs/PDFs) which are called out by name.

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 ('right before sending user data to an LLM/third party') plus an explicit WHEN NOT that routes to two named siblings with the conditions that select each. It also gives an internal usage decision (returnPlaceholderMap=true when you need to restore later).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources