fairquery-agent-trust-mcp

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Deep PII/secret guard for documents and URLs (paid)

pii_guard_documents

Read-onlyIdempotent

Detect and redact PII, secrets, names, and addresses in text, PDFs, or public document URLs; restore originals with placeholder maps.

Instructions

WHAT: Runs the Fairquery Apify Actor llm-data-guard-pii-secrets: everything pii_scan_text does PLUS person-name/location NER, street addresses, public document URLs (txt/md/json/csv/HTML/PDF text layer, <= 10 MB) and restore mode (put originals back into LLM output using a placeholder map). WHEN: You need NER names/addresses, need to scan files at URLs/PDFs, or want the hosted pipeline. For plain text with regex-detectable PII/secrets prefer free pii_scan_text / pii_redact_text. WHEN NOT: Plain text scans (free tools), images (no OCR), email deliverability. COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.003 per document + $0.0005 per finding (Actor fairquery/llm-data-guard-pii-secrets). Example: 10 docs with 20 findings ~ $0.04. RETURNS: Paged rows: type="document" (id, source, chars, mode, finding_count, counts_by_type, risk_level, findings[] masked, output_text, placeholder_map if requested) or type="error". Tool errors: APIFY_TOKEN_MISSING, APIFY_TOKEN_INVALID, APIFY_PAYMENT_REQUIRED, APIFY_ACTOR_RUN_FAILED, APIFY_TIMEOUT, INPUT_EMPTY. BEHAVIOR: Read-only (does not modify your data), idempotent. Makes network calls: runs an Apify Actor billed to your APIFY_TOKEN; may fetch documentUrls. Latency seconds to a few minutes (300 s actor timeout). Up to 1000 texts / 100 URLs (10 MB each). PARAMETERS: texts or documentUrls = input (one required); mode = detect | redact | restore (default redact); redactionStyle (default placeholder); returnPlaceholderMap (default false); placeholderMap = map for restore mode; detectNames / detectAddresses = NER for names / addresses (default false); entropyScan (default false); entityTypes / allowList = restrict / exempt values; limit = page size (default 100, max 1000); offset = items to skip for paging (default 0). EXAMPLE: {"documentUrls":["https://example.com/report.pdf"],"mode":"redact","detectNames":true}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	"detect" findings only; "redact" (default) also output_text; "restore" replaces placeholders in texts using placeholderMap	redact
`limit`	No	Page size: items to return, integer 1-1000 (default 100)
`texts`	No	Documents as strings (each <= 1,000,000 chars, max 1000). Optional if documentUrls given
`offset`	No	Items to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response
`allowList`	No	Values never flagged
`detectNames`	No	Person-name NER (default false)
`entityTypes`	No	Restrict types, e.g. ["EMAIL","PERSON"]
`entropyScan`	No	Flag high-entropy tokens (default false)
`documentUrls`	No	Public http(s) URLs of txt/md/json/csv/HTML/PDF files (<= 10 MB each), fetched by the Actor in Apify cloud, max 100. Example: ["https://example.com/a.pdf"]
`placeholderMap`	No	For mode="restore": {"[EMAIL_1]":"jane@acme.com"}
`redactionStyle`	No	Redact style (default placeholder)	placeholder
`detectAddresses`	No	Street addresses + place-name NER (default false)
`returnPlaceholderMap`	No	Include placeholder_map with original values (default false)

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	No	Tool-specific context (summary counts, cost notes, ...)
`count`	Yes	Number of items in this page
`items`	Yes	Result rows for this page
`total`	Yes	Total items before paging
`offset`	Yes	Offset of the first item in this page
`hasMore`	Yes	True if more items exist after this page
`nextOffset`	Yes	Offset to pass for the next page, or null

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?

Goes well beyond the readOnlyHint/idempotentHint annotations: it discloses the exact cost model ($0.003/doc + $0.0005/finding billed to the caller's APIFY_TOKEN), that network calls occur to an Apify Actor and to documentUrls, latency (seconds to minutes, 300 s timeout), volume caps, and the concrete error codes returned (APIFY_TOKEN_MISSING, APIFY_PAYMENT_REQUIRED, etc.). This is exactly the paid-side-effect context an agent needs to decide whether to invoke.

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?

Labeled WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE structure is well front-loaded and scannable. It is long, and the PARAMETERS block partially duplicates a 100%-covered schema, so a few lines do not fully earn their place.

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 13-parameter, nested-object, paid, open-world tool, the description covers inputs, alternatives, cost, latency, limits, error surface, and return shape (even though an output schema exists). An agent has everything needed to call it correctly and predict the consequences.

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 PARAMETERS block adds genuinely new information: the constraint that one of texts/documentUrls is required (the schema declares no required fields), the detect/redact/restore semantics including how placeholderMap is consumed, and an end-to-end EXAMPLE. It slightly restates defaults already in the schema, keeping it short of a 5.

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?

The WHAT line states a specific capability (PII/secret guarding) and explicitly positions it relative to a sibling: 'everything pii_scan_text does PLUS' NER names/locations, addresses, URL/PDF scanning, and restore mode. An agent can distinguish this from pii_scan_text and pii_redact_text without opening any 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 and WHEN NOT sections name the selecting conditions (need NER names/addresses, need URL/PDF scanning, want the hosted pipeline) and explicitly route plain-text regex cases to the free pii_scan_text / pii_redact_text, while excluding images and email deliverability. Nothing is left 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