fairquery-llm-data-guard

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Restore placeholders with original values (free, local)

restore_placeholders

Read-onlyIdempotent

Puts original values back into LLM answers that contain placeholders from a guard_text redact call, so users see real data after redaction.

Instructions

WHAT: The last step of the round trip and the default way to restore: puts original values back into texts (typically an LLM answer) that contain placeholders such as [EMAIL_1], using the placeholder_map from a guard_text redact call. Does no detection. WHEN TO USE: after the LLM answered a prompt you redacted with guard_text (mode="redact", redactionStyle="placeholder", returnPlaceholderMap=true), before showing the answer to the user. Prefer it over guard_text mode="restore": same output_text, but free and local. WHEN NOT TO USE: to find or redact PII/secrets (guard_text) or list entity types (list_detectors). Masked and hashed values cannot be restored; only placeholder style is reversible. BEHAVIOR: no network call; the map never leaves your machine; milliseconds. Up to 1000 texts and 5,000,000 chars in total per call. COST: free; no APIFY_TOKEN. RETURNS: replacements counts substituted placeholders; unknown_placeholders lists [TYPE_N] tokens the map does not cover (left as is, e.g. invented by the LLM). Errors: INPUT_TOO_LARGE. The output holds the ORIGINAL sensitive values: show it to the user, do not send it back to the LLM. PARAMETERS: placeholderMap must be the map of the redact call that produced the placeholders (numbering restarts on every call); only [UPPERCASE_TYPE_N] keys are used (exact, case-sensitive, one pass). A placeholder the LLM rewrote (e.g. "EMAIL_1" without brackets) is not restored. EXAMPLE: {"texts":["I will email [EMAIL_1] today."],"placeholderMap":{"[EMAIL_1]":"jane@acme.com"}} -> output_text "I will email jane@acme.com today.", replacements 1.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`texts`	Yes	Required. 1-1000 texts containing placeholders, 5,000,000 chars in total. Example: ["I will email [EMAIL_1] today."]
`placeholderMap`	Yes	Required. Object placeholder -> original value, exactly as returned in placeholder_map by a guard_text redact call. Example: {"[EMAIL_1]":"jane@acme.com"}

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes	Number of rows in items
`items`	Yes	type=restored_document rows (doc_index, chars, replacements, unknown_placeholders, output_text)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Oct 18, 2026

TDQS

A5/5.0

Behavior5/5

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

Goes well beyond annotations: discloses no network call, the map never leaves the machine, millisecond latency, size limits (1000 texts / 5,000,000 chars), cost (free, no APIFY_TOKEN), what cannot be restored (masked/hashed), and a critical safety caveat that output contains original sensitive values and must not be sent back to the LLM. Annotations already say readOnly/idempotent/non-destructive; description adds local-only execution and data-handling warnings.

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 WHAT/WHEN TO USE/WHEN NOT TO USE/BEHAVIOR/COST/RETURNS/PARAMETERS/EXAMPLE headings make it scannable. Despite length, each section carries distinct, actionable content with no filler; the example is compact and illustrative.

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 everything an agent needs: correct sequencing, alternatives, local-only guarantee, limits, cost, return fields (replacements, unknown_placeholders), the INPUT_TOO_LARGE error, and the sensitive-output handling rule. With an output schema present, the description still adds the 'do not send back to LLM' caveat that the schema cannot express.

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 100% and the description still adds meaning: placeholderMap must come from the exact redact call that produced the placeholders, numbering restarts per call, only [UPPERCASE_TYPE_N] keys within brackets are used, matching is exact, case-sensitive, and single-pass, and a rewritten placeholder without brackets is not restored. These are behavioral semantics not captured by 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?

The WHAT section states a specific verb (restore/put back), resource (original values into texts with placeholders), and positions it as 'the last step of the round trip and the default way to restore'. It explicitly names the counterpart guard_text and its mode, so an agent can distinguish it from siblings without opening schemas.

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?

Provides explicit WHEN TO USE (after guard_text redact with placeholder style, before showing user), WHEN NOT TO USE (finding/redacting PII -> guard_text, listing types -> list_detectors), and a preference rule (prefer over guard_text mode=restore because free and local). This is textbook when/when-not/alternatives guidance.

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

Deploy Server