Skip to main content
Glama
fairquery

fairquery-agent-trust-mcp

Official

Scan text for PII and secrets locally (free)

pii_scan_text
Read-onlyIdempotent

Scan text locally for PII and secrets like emails, cards, API keys, and tokens before sending prompts, logs, or files to LLMs or third parties.

Instructions

WHAT: Detect PII (emails, phones, US SSNs, Luhn-valid cards, mod-97 IBANs, UK NINOs, IPv4/IPv6) and secrets (AWS/GitHub/GitLab/Slack/Stripe/Google/OpenAI/Anthropic/HF/npm/SendGrid/Twilio/Azure keys, JWTs, private keys, URL credentials, key=value secrets) in text. Runs 100% on your machine. WHEN: Before sending prompts, tickets, logs or files to an LLM or third party; to audit text for leaked credentials. Findings are paged across all documents. WHEN NOT: To get sanitized text use pii_redact_text. For person names/addresses (NER), public URLs or PDFs use pii_guard_documents (paid). Not for images (no OCR). COST: Free. Local regex/validators only; no network, no APIFY_TOKEN, nothing sent anywhere. RETURNS: Paged {count,total,offset,hasMore,nextOffset,meta:{documents:[{doc_index,chars,finding_count,counts_by_type,risk_level}]},items:[{doc_index,type,category,rule,start,end,confidence,masked}]}. Raw values are never returned. Errors: INPUT_TOO_LARGE. EXAMPLE: {"texts":["Mail jane@acme.com, key AKIAIOSFODNN7EXAMPLE"]} -> 2 findings: EMAIL (masked "j***@a***.com"), AWS_ACCESS_KEY; risk_level "critical".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size: items to return, integer 1-1000 (default 100)
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"]
offsetNoItems to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response
allowListNoExact values never flagged (case-insensitive), e.g. ["support@yourco.com"]. Default []
entityTypesNoOnly report these types, e.g. ["EMAIL","CREDIT_CARD","AWS_ACCESS_KEY"]. Omit = all local detectors. Valid names: pii_list_detectors
entropyScanNoAlso flag unlabeled random-looking 20-200 char tokens as HIGH_ENTROPY_STRING (default false; may flag hashes/IDs)
defaultPhoneRegionNoISO 3166-1 alpha-2 region for phones without +prefix, e.g. "US" (default), "DE", "GB"US

Output Schema

TableJSON 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 observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, but the description adds substantial context beyond them: 100% local execution, no network or APIFY_TOKEN, raw values never returned, findings paged across documents, and the INPUT_TOO_LARGE error. This is materially richer than the annotation set.

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?

The WHAT/WHEN/WHEN NOT/COST/RETURNS/EXAMPLE labeling makes it well front-loaded and skimmable. It is somewhat long, and the RETURNS block partially restates the existing output schema, which is a minor redundancy rather than a clarity problem.

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 an idempotent local read tool with an output schema, no annotations gaps, and complete parameter docs, this definition covers purpose, alternatives, cost/privacy posture, paging, and error handling. An agent has everything needed to call it correctly.

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 description coverage is 100%, so the schema already documents all seven parameters and the baseline would be 3. The description adds an end-to-end input/output example and cross-references pii_list_detectors for valid entityTypes names, giving modest extra value beyond the schema text.

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?

Names a precise verb (detect/scan) and resource (text) and enumerates the concrete detector families (emails, SSNs, Luhn cards, AWS/GitHub/etc. keys, JWTs), so the agent knows exactly what is covered. It explicitly differentiates from siblings by naming pii_redact_text for sanitization and pii_guard_documents for NER/PDFs.

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?

A dedicated WHEN clause covers the intended scenarios (pre-LLM/third-party sending, credential auditing) and a WHEN NOT clause routes the agent to specific alternatives (pii_redact_text, pii_guard_documents) with the condition that selects them. No inference required.

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