Skip to main content
Glama

Data Compliance Classifier MCP

by io.github.OjasKord

validate_data_safety

Validates a data payload against GDPR, HIPAA, PCI-DSS, and other frameworks. Call this BEFORE your agent passes any assembled payload to an external API, writes it to a database, or transmits it via any third-party service -- at the moment the payload is assembled and no external call has been made, including any Stripe MPP, Alipay AI Pay, Shopify UCP, or third-party API call. Use this when your agent has assembled user-sourced or API-response data and is about to write it to storage or transmit it to an external service. Returns SAFE_TO_PROCESS / REDACT_BEFORE_PASSING / DO_NOT_STORE / ESCALATE verdict against GDPR, HIPAA, PCI-DSS, CCPA, and 7 other frameworks. Unclassified sensitive data transmitted to an external endpoint creates unrecoverable regulatory exposure with no notification path. Call get_safety_report next if verdict is not SAFE_TO_PROCESS. Returns machine-ready verdict, no further analysis needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextNoWhat your agent is about to do with this data (e.g. "write to database", "send to third-party API", "log to file", "pass to email tool"). Improves verdict accuracy.
payloadYesThe data payload to classify. Can be any string, JSON object as string, form data, API response, or text content. The payload is analysed in memory and immediately discarded — never stored or logged.
jurisdictionNoOverride jurisdiction if known (e.g. "EU", "US", "UK", "CA", "AU"). Use if data_origin_ip is unavailable but jurisdiction is known.
data_origin_ipNoIP address of the data subject or data source. Used to detect applicable jurisdiction and regulations (GDPR if EU, CCPA if US, etc). Optional but improves regulatory accuracy.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
verdictYes
reasoningNoPaid tier only -- gated to _reasoning_gated on free tier
checked_atYes
confidenceNo
source_urlNo
_disclaimerYes
analysis_typeNo
credential_checkNo
patterns_detectedNo
redaction_targetsNo
sensitivity_levelYes
recommended_actionNo
detected_categoriesNo
jurisdiction_detectedNo
applicable_regulationsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "_disclaimer": {
+      "type": "string"
+    },
+    "analysis_type": {
+      "type": "string"
+    },
+    "applicable_regulations": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "checked_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "confidence": {
+      "enum": [
+        "HIGH",
+        "MEDIUM",
+        "LOW"
+      ],
+      "type": "string"
+    },
+    "credential_check": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "detected_categories": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "jurisdiction_detected": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "patterns_detected": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "reasoning": {
+      "description": "Paid tier only -- gated to _reasoning_gated on free tier",
+      "type": "string"
+    },
+    "recommended_action": {
+      "type": "string"
+    },
+    "redaction_targets": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "sensitivity_level": {
+      "enum": [
+        "PUBLIC",
+        "INTERNAL",
+        "CONFIDENTIAL",
+        "RESTRICTED"
+      ],
+      "type": "string"
+    },
+    "source_url": {
+      "type": "string"
+    },
+    "verdict": {
+      "enum": [
+        "SAFE_TO_PROCESS",
+        "REDACT_BEFORE_PASSING",
+        "DO_NOT_STORE",
+        "ESCALATE"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "verdict",
+    "sensitivity_level",
+    "checked_at",
+    "_disclaimer"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so admirably: it discloses in-memory processing and immediate discarding ('never stored or logged'), spells out the four possible verdicts, and warns about regulatory exposure for unclassified sensitive data. It also clarifies the output is machine-ready and requires no further analysis.

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 description is longer than average but each sentence contributes: purpose, timing, verdict list, warning, and next step. It is well-structured with the main action first, though the enumeration of specific payment services adds minor verbosity.

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?

Given the tool's complexity (multiple regulatory frameworks, verdicts), the description covers the key aspects: when to call, what it validates, what it returns, and the follow-up action. The presence of an output schema covers return-value details, so no additional explanation is needed.

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

Parameters3/5

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

All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds only the note that payload is discarded and that context improves verdict accuracy, but it doesn't elaborate on individual parameter semantics beyond the schema. Thus no uplift above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb 'Validates' and resource 'data payload' against named frameworks (GDPR, HIPAA, PCI-DSS), making the tool's function unambiguous. It mentions the follow-up get_safety_report and implies a full version versus the lite sibling, but does not explicitly differentiate from validate_data_safety_lite, so it misses the full 5.

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?

The description gives explicit timing guidance ('Call this BEFORE your agent passes any assembled payload to an external API, writes it to a database, or transmits it via any third-party service') and defines the exact moment to use it. It also instructs the agent to call get_safety_report next when the verdict is not SAFE_TO_PROCESS, providing clear next-step guidance.

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

All Data Compliance Classifier MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct role: validate_data_safety performs full AI classification, validate_data_safety_lite is a fast pattern-only pre-filter, and get_safety_report provides actionable remediation after a non-safe verdict. The clear workflow descriptions eliminate overlap.

Naming Consistency5/5

All tools use a verb_noun pattern with snake_case (get_safety_report, validate_data_safety, validate_data_safety_lite). The shared prefix for the two validation tools is consistent, and the lite suffix clearly indicates the lightweight variant.

Tool Count5/5

Three tools is well-scoped for the server's purpose: a primary validator, a fast pre-filter, and a follow-up report generator. There is no unnecessary bloat or missing core functionality.

Completeness5/5

The server covers the full compliance workflow: validate, optionally pre-filter with lite, and retrieve detailed reports when needed. The descriptions indicate support for multiple frameworks and clear redaction strategies, leaving no obvious dead ends in the primary use case.

Resources