Skip to main content
Glama

sqltwin_stream_anonymize

Read-onlyIdempotent

Anonymizes PostgreSQL and MySQL SQL dumps by replacing PII with synthetic values while preserving foreign key joins, referential integrity, and unique constraints for staging or test copies.

Instructions

Streams and anonymizes PostgreSQL and MySQL database dumps, replacing PII (emails, phone numbers, names, IBANs) with synthetic values using HMAC format-preserving encryption while preserving 100% of foreign key joins, relational referential integrity, and unique constraints. Use when: Preparing staging or developer test database copies from production SQL dumps without exposing real user identities. Do not use when: Parsing financial SEC EDGAR filings or classifying IP addresses. Alternative: Use edgarpulse_parse_filing for SEC regulatory filings, or cidr_shield_lookup for IP address classification. Execution: Runs locally in-memory (<10ms), deterministic, zero network calls, zero telemetry, air-gapped deterministic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sqlContent": "<sqlContent>"
    },
    "name": "sqltwin_stream_anonymize"
  }
}

Input Schema

NameRequiredDescriptionDefault
licenseKeyNoOptional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).
secretSaltNoOptional cryptographic HMAC salt for deterministic pseudonymization (default: 'mcp-salt').
sqlContentYesRaw SQL dump content containing CREATE TABLE, COPY, or INSERT statements.

Output Schema

NameRequiredDescriptionDefault
anonymizedSqlYesSanitized SQL content with preserved referential integrity.
rowsProcessedYesTotal count of SQL data rows parsed and anonymized.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.6
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / licenseKey
      Added value: +{
      +  "description": "Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).",
      +  "type": "string"
      +}
    • changedInput schema / properties / secretSalt / description
      Previous value: -"HMAC salt for deterministic pseudonymization"New value: +"Optional cryptographic HMAC salt for deterministic pseudonymization (default: 'mcp-salt')."
    • changedInput schema / properties / sqlContent / description
      Previous value: -"Raw SQL dump content"New value: +"Raw SQL dump content containing CREATE TABLE, COPY, or INSERT statements."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "anonymizedSql": {
      +      "description": "Sanitized SQL content with preserved referential integrity.",
      +      "type": "string"
      +    },
      +    "rowsProcessed": {
      +      "description": "Total count of SQL data rows parsed and anonymized.",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "rowsProcessed",
      +    "anonymizedSql"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuine context beyond them: processes locally in-memory, <10ms, deterministic, zero network calls, zero telemetry. The deterministic HMAC behavior also tells the agent results are reproducible, which is not in the annotations.

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 with the core action, then explicitly sectioned into Use when / Do not use when / Alternative / Execution. Every sentence carries decision-relevant information; even the execution note adds trust/performance context.

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?

With a full output schema, complete parameter descriptions, and rich annotations, the remaining burden on the description is routing and behavioral context — both fully covered. 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 coverage is 100%, so baseline is 3; the description earns an extra point by explaining the HMAC mechanism and determinism, which is exactly the semantics behind the optional secretSalt choice. It does not explicitly discuss licenseKey or salt-change consequences, so it stops short of 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?

States a specific verb and resource ('streams and anonymizes PostgreSQL and MySQL database dumps') plus the mechanism (HMAC format-preserving encryption) and the invariants preserved (FK joins, referential integrity, unique constraints). This is clearly distinguishable from every sibling tool.

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?

Explicitly gives a 'Use when' scenario (staging/dev copies from production dumps), a 'Do not use when' exclusion (SEC EDGAR parsing, IP classification), and names the two alternative tools by name for those cases.

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