fairquery-llm-data-guard

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

List detectable types and redaction styles (free, local)

list_detectors

Read-onlyIdempotent

Lists supported PII and secret detector types, redaction styles, and billable events to help choose options before redacting text.

Instructions

WHAT: Reference data, not a scan: the PII and secret entity types guard_text can detect, its redaction styles and its billable events. Inspects no text. WHEN TO USE: optional step 1, before guard_text, to choose entityTypes / redactionStyle, to estimate guard_text cost, or to explain coverage to a user. WHEN NOT TO USE: to check whether a given text contains PII or secrets (guard_text; this catalog cannot tell you that). Not needed before every guard_text call: guard_text runs all default detectors when entityTypes is omitted. To undo a redaction, restore_placeholders. BEHAVIOR: the catalog ships with this server version and is not fetched from the Actor, so a newer Actor build can support types that an older server version does not list. COST: free; no APIFY_TOKEN. RETURNS: pii / secret entries are valid guard_text entityTypes once the parenthesised note is dropped ("CREDIT_CARD (Luhn)" -> "CREDIT_CARD"); "opt-in" entries need guard_text detectNames / detectAddresses / entropyScan; redaction_styles keys are the allowed redactionStyle values (only "placeholder" can be undone with restore_placeholders). PARAMETERS: none; call with {}. EXAMPLE: {} -> {"pii":["EMAIL","PHONE",...],"secret":["AWS_ACCESS_KEY",...],...}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`pii`	Yes	PII entity types (opt-in ones marked)
`secret`	Yes	Secret/credential entity types
`pricing_events`	Yes	Billable Apify event -> unit
`redaction_styles`	Yes	Redaction style -> example output

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial non-obvious context: the catalog is version-pinned to the server rather than fetched from the Actor, so newer Actor builds may support unlisted types; it is free and needs no APIFY_TOKEN. This is exactly the kind of behavioral detail annotations cannot express.

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?

Heavy but front-loaded and labelled (WHAT / WHEN / WHEN NOT / BEHAVIOR / COST / RETURNS / PARAMETERS / EXAMPLE), so an agent can scan to the needed section. The RETURNS block is somewhat long for a tool that has an output schema, though its guidance on stripping parenthesised notes and the 'opt-in' flags is genuinely actionable rather than padding.

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?

For a zero-parameter, read-only catalog with a full output schema, the description supplies everything else an agent needs: cost, token requirements, version-skew caveat, and how to translate returned entries into valid guard_text arguments. Nothing required to call 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?

Zero parameters, so the baseline is 4; schema coverage is 100% and the description confirms 'none; call with {}'. It adds no per-parameter meaning because none exists, but the call convention is stated unambiguously.

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 a specific resource — the catalog of PII/secret entity types and redaction styles — and immediately disambiguates it from scanning ('Reference data, not a scan... Inspects no text'). The distinction from guard_text is explicit, so an agent can route correctly without opening either 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?

Dedicated WHEN TO USE and WHEN NOT TO USE sections name the concrete triggers (choose entityTypes/redactionStyle, estimate cost, explain coverage) and the anti-triggers (checking text → guard_text; undoing redaction → restore_placeholders; not needed before every guard_text call since defaults apply). Alternatives are named, not implied.

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

Deploy Server