DEV Community: Khalid Elokiely

Why Your Agentic SaaS Shouldn't Store Client Data — Even Encrypted

Khalid Elokiely — Wed, 08 Jul 2026 09:07:37 +0000

The MCP Dev Summit 2026 consensus was that "behind every corporate firewall, MCP is being quietly wired to systems of record and company data all day long" — but nobody is writing about the architectural implications for SaaS vendors who want to offer agentic features without becoming data processors.

The Obvious Solution

If you are thinking of creating an Agentic AI SaaS that potentially could be used by enterprise clients, you might have already thought about how to let your Agentic platform work with client data. The obvious move is:

ETL their data into your platform, encrypt it, build on top of it.

This is what most teams do. It’s what LLM tutorials show. And it is the wrong call.

Encryption Is A Mirage

Encryption doesn't solve the liability problem. If client data lives on your persistence layer, you're a data processor under GDPR, SOC2, HIPAA — regardless of your encryption key.

The compliance team at your enterprise prospect knows this. Their legal team knows this. It’s why deals stall at the data handling clause every time.

The zero-knowledge architecture becomes a sales unlocker, not just a security pattern.

The Zero-Knowledge Architecture

What if the SaaS never ingested the data at all?

Here's what the flow actually looks like when the SaaS never touches the data.

The above sketch shows a way out of data processing responsibility.

This is where the Zero-Knowledge architecture begins to diverge from the previous ETL architecture.

The client sends the same query “Get me an aggregate of sales by region” to your SaaS.
The SaaS takes the natural language prompt and:
1. Passes it to an LLM loaded with the client's MCP connection details. The LLM begins reaching out to the client's data gateway.
2. The LLM asks the client’s MCP gateway: What tools do you have (get_tools)?
The MCP gateway responds with: Well, I have list_tables and get_metrics .
The LLM in this step has access to tools only allowed by the client. It begins to discover capabilities.
1. The LLM reads both tool descriptions and selects get_metrics tool, which is described as *Retrieves aggregated metrics for specified geographical regions*
2. LLM sends the regions over to the get_metrics tool and receives the response with something like:

[
  {
    "region": "New Cairo",
    "unitsSold": 165,
    "totalRevenue": 1245000000,
    "cancelledOrders": 3
  },
  {
    "region": "North Coast",
    "unitsSold": 12,
    "totalRevenue": 180000000,
    "cancelledOrders": 4
  }
]

The LLM then takes these metrics, formulates a response and sends it back to the user.

But wait! MCP connection details? list_tables? Isn’t that the same thing as storing the data with just another network hop?

Creating a Zero-Knowledge MCP Gateway that lives inside the client’s perimeter means the client’s raw records never leave their infrastructure. The MCP gateway is a hardened layer that only allows pre-computations that the client finds meaningful.

The list_tables tool — explained in depth in the linked article — is a deliberate architectural choice. It allows the LLM to discover what capabilities the MCP server exposes, without ever seeing the data those capabilities operate on. The attacker in the corner of Diagram 2 isn't confused because the security is sophisticated. He's confused because there's nothing there. No storage to breach. No records to exfiltrate. No target.

What Actually Lives In Your Storage

Diagram 2 makes this explicit.
The SaaS only stores user accounts, states, agentic flows currently running, MCP connection details. That’s it. That’s all your SaaS needs to know to curate a successful 2-way street between your proprietary software and the client’s data gateway.

You manage the orchestration graph, but you never touch the data it operates on. This distinction is your entire compliance posture.

The Sales Argument

"We never ingest your data" is not a security feature. It's a contract clause that closes enterprise deals. When enterprise clients don't have to worry about migrations or ETLS - the conversation becomes so much easier.

Every data handling negotiation that stalled your competitor just became a non-conversation for you.

What Comes Next

The MCP gateway removes the data from your attack surface. But TEE-backed attestation removes the compute from your trust surface. That's the next layer — and the subject of the next article.

Links In This Article:

Building a Zero-Leak Postgres MCP Gateway in Go

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.

How Egyptian FRA Regulations Built Better FinTech Architecture

Khalid Elokiely — Sat, 04 Jul 2026 19:09:28 +0000

When our team started building the backend for a licensed NBFI under Egyptian financial regulations, compliance felt like a list of things we couldn't do. We couldn't use a shared global deployment. We couldn't integrate a foreign KYC provider. We couldn't use a standard database table for financial records. What we discovered, six months into the build, is that every single constraint the FRA (Financial Regulatory Authority) imposed was pointing us toward an architecture we should have built anyway. This is that architecture.

Four Hard Constraints, One Architecture

The Egyptian Financial Regulatory Authority (FRA) frames a secure and sustainable fintech gateway as an integrated system with four constraints mentioned through two key regulatory decisions: 139/2023, 140/2023

Your Data Doesn't Leave Egypt
You Can't Buy Identity Off the Shelf (KYC)
The Regulator Will Ask For Five Years of Proof
An UPDATE Statement Is a Compliance Violation

Your Data Doesn't Leave Egypt

The FRA is explicit: hardware, database servers, application servers, and web servers must physically reside within Egypt's geographic borders. A shared global cloud deployment with no regional isolation strategy fails this requirement on day one.
The two realistic paths are a local data center provisioned through an Egyptian vendor, or a solution like AWS Outposts; which runs AWS-managed infrastructure on your premises, letting your team work with familiar tooling while satisfying the physical residency requirement. For Kubernetes specifically, the defensible pattern under audit is a dedicated cluster per regulatory zone, not just namespace isolation. Namespaces share underlying nodes; under a strict physical audit, that shared compute is a risk you don't want to defend.

You Can't Buy Identity Off the Shelf

FRA Decision 140/2023 explicitly states: identity verification must use the Egyptian National ID system — a document that is legally recognized across all financial and telecom records in Egypt — and the phone number must be registered under that same national ID.That last requirement might sound like administrative redundancy. It isn't.

The MFA framework defines three authentication categories.

Something you know: the PIN or password the user sets at registration.
Something you have: access to their registered phone number, email, or national ID document.
Something you are: the live biometric scan — the facial recognition and liveness check that confirms the person holding the ID is the person creating the account.

The FRA's requirement that the phone number link back to the national ID isn't a fourth step — it collapses the second and third categories into one verifiable chain. The phone number is registered to a national identity. The biometric confirms the identity is present and alive. There is no gap between "someone has this number" and "this person is who they claim to be."

From a development standpoint, the KYC interface must be swappable. KYC vendors design flows that create lock-in — proprietary SDKs, non-portable session tokens, verification states that live in their systems rather than yours. When terms change or quality drops, migration becomes a re-enrollment exercise for your entire user base.

The architectural answer is to treat KYC as a side effect, not a dependency. Your domain retains the artifacts of verification — the national ID hash, the verified phone number, the liveness result, the assigned trust tier, and the timestamp — in a normalized format that belongs to your system. A new provider receives these artifacts and resumes from the correct trust level. The user never re-verifies from scratch. This is not just good architecture; it is what Decision 140/2023 implicitly demands when it defines three distinct trust tiers that must persist across sessions and remain auditable for five years.

type KYCProvider interface {
    InitiateVerification(ctx context.Context, req VerificationRequest) (*Session, error)
    CheckStatus(ctx context.Context, sessionID string) (*VerificationResult, error)
    FetchArtifacts(ctx context.Context, sessionID string) (*KYCArtifacts, error)
}

type KYCArtifacts struct {
    NationalIDHash    string
    VerifiedPhone     string
    LivenessConfirmed bool
    TrustTier         TrustTier
    VerifiedAt        time.Time
}

The implementation behind this interface is a detail. The artifacts it produces belong to your domain permanently

The Regulator Will Ask For Five Years of Proof

Decision 139/2023 mandates a security baseline that reads like a SOC2 checklist before your first engineer writes a line of application code: next-generation firewall, web application firewall, asset monitoring across all systems, security isolation between services by sensitivity level, annual penetration testing with submitted reports to the FRA, and unique session IDs with timestamps on every connection.

The hardest requirement to retrofit is also the most specific: all system logs, security logs, and application logs must be retained for no less than five years from the date of the event. Full transaction logs — every login, every logout, every financial operation — for the same period.

Five years is not a backup policy. It is a forensic requirement. The FRA is stating that five years from now, a regulator must be able to reconstruct exactly what happened in your system on any given day. That reconstruction is only possible if logging was part of your domain model from day one — not a middleware you added in sprint twelve.

The architectural consequence is straightforward: every domain event is a first-class record. Not a log line written to stdout. Not an entry in a monitoring dashboard that rotates after 90 days. A structured, timestamped, indexed record that lives in the same persistence tier as your business data, subject to the same retention guarantees. If your observability stack and your business data have different retention policies, you have already failed this requirement. The FRA does not distinguish between "application logs" and "transaction records" in its five-year mandate. Neither should your architecture.

An UPDATE Statement Is a Compliance Violation

Immutability in financial systems doesn't mean the data store throws an error when you try to edit a record. It means the system is designed so that editing a record is never the right operation — only appending a new one is.

// ImmutableLedger enforces append-only financial state.
// No entry is ever modified or deleted - only superseded.
type ImmutableLedger[T any, ID comparable] interface {
    // CreateEntry appends a new record to the ledger.
    // The rolling balance is computed from all prior entries
    // for this account — never stored as mutable state.
    CreateEntry(ctx context.Context, accountID ID, record T) error

    // ReverseEntry does not delete. It creates an equal and
    // opposite entry that cancels the effect of the original.
    // Both entries remain permanently visible in the audit trail.
    ReverseEntry(ctx context.Context, originalID ID, reason string) error

    // History returns the full, ordered, unmodified chain
    // of entries for an account. The current balance is the
    // sum of this chain — always derivable, never cached mutably.
    History(ctx context.Context, accountID ID) ([]T, error)
}

// Transaction is the canonical ledger entry.
// Once written, no field changes. Ever.
type Transaction struct {
    ID            string
    AccountNumber string
    FromAccount   string
    ToAccount     string
    Debit         decimal.Decimal
    Credit        decimal.Decimal
    RollingBalance decimal.Decimal // computed at write time, never updated
    Description   string
    CreatedAt     time.Time
    ReversalOf    *string // non-nil if this entry reverses a prior one
}

Notice what's absent: there is no UpdateEntry. There is no DeleteEntry. These operations don't exist because they have no valid meaning in a financial ledger. A wrongly recorded transaction isn't corrected by overwriting it — it's corrected by recording the reversal. Both entries remain. The audit trail is complete. A regulator asking "what happened to this account on this date" gets a chain of immutable facts, not a current state that may have been edited twelve times since the event occurred.

The rolling balance is never stored as a mutable field that gets updated on each transaction. It is computed from the full chain of entries at write time and recorded as part of that entry. If you need the current balance, you read the most recent entry. If you need to audit, you read all of them. The source of truth is the chain — not any single record within it.

This is the pattern the FRA mandates when it states that digital records must carry "the evidentiary weight of official instruments" from the moment of their creation. An UPDATE statement issued after the fact destroys that evidentiary weight. An append-only ledger preserves it by design.

Formance is an open source financial core which implements this pattern at production scale — with multi-currency support, account hierarchies, and a query layer built specifically for financial audit — without requiring you to enforce these constraints manually across your codebase. The interface above describes the contract; Formance is one of the most elegant implementations of it available as open infrastructure today.

For a ledger like Formance, an append only immutable ledger API spans the following operations

# 1. Append a completely new, unchangeable transaction to the log
POST /api/ledger/main_ledger/transactions  {"script": {"plain": "send [EGP/2 100] (source = @users:001 destination = @merchant:checkout)"}}

# 2. Retrieve the full, permanent transaction history for an account
GET /api/ledger/main_ledger/accounts/users:001/transactions

Regulation as Architecture: A Pattern That Travels

These patterns didn't originate with the FRA. They are the global consensus on what regulated financial infrastructure looks like. The pattern suggested by FRA regulations are actually more widespread and mandated internationally by all regulatory bodies across the EU and APAC.

FRA Constraint	Architectural Pattern	EU Equivalent	APAC Equivalent
Data residency in Egypt	Regional isolation	GDPR Article 44	MAS TRM (Singapore)
Egyptian KYC providers only	Pluggable provider interface	PSD2 SCA	RBI KYC (India)
5-year immutable logs	Event sourcing / ledger	SOX Section 802	HKMA record retention
Accounting always visible	Double-entry ledger	PSD2 audit trail	MAS audit requirements

The FRA didn't hand our team a list of architectural best practices. It handed us a list of regulatory requirements. But when we mapped each requirement to its implementation, what emerged wasn't a compliance checklist — it was a backend that was genuinely harder to break, easier to audit, and more honest about what it was doing with user data.

Regional isolation because the law required it. Pluggable KYC because the law required it. Five-year event logs because the law required it. Append-only ledger because the law required it.

Every one of those decisions would have been the right call without the regulation. The regulation just made the conversation shorter.

If you're building financial infrastructure — in Egypt, in the EU, in Southeast Asia, anywhere a regulator has an opinion about where your data lives and how long you keep it — the constraints are not the obstacle. They are the specification. Build to them first, and the architecture takes care of itself.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.

Building a Zero-Leak Postgres MCP Gateway in Go

Khalid Elokiely — Fri, 26 Jun 2026 17:28:58 +0000

The promise of agentic AI workflows introduces a real architectural problem: to make an LLM useful, you need to give it some awareness of your data. But every common approach forces a bad trade-off. Hand an external orchestrator direct database access and you risk leaking everything. Serialize your schema into a third-party context window and your internal data structure — the thing your product is actually built on — lives outside your perimeter. For a real estate consultancy, that means compound pricing structures and transaction history sitting in a shared cloud context just to answer an analytical prompt. For a FinTech platform, it means exposing account schemas to an inference engine that was never audited for your compliance requirements. Neither is acceptable.

This article shows a third path: a lightweight Go gateway that sits between the LLM and your database, built on the Model Context Protocol. It gives the LLM exactly two things — a view of what data domains exist, and a fixed set of computations it's allowed to run against them. No raw rows. No open query interface. No schema exposure upstream. You will build this from scratch: schema reflection that auto-discovers your database structure at startup, and pre-defined aggregation tools that return only what the business needs. The LLM gets answers. Your data stays where it belongs.

The project follows a standard go folder layout - cmd/ for the entrypoint, pkg/db for the Postgres connection and logic. This isn’t a framework requirement, just a convention that keeps schema reflection, query execution and MCP transport cleanly separated. You can flatten this into a single file for prototyping.

The MCP zero-leak architecture

Three things make this gateway zero-leak;

Schema Visibility: What it’s allowed to see from the data source (EXPOSED_TABLES)
Aggregation: What it’s allowed to compute
Tool Registration to the MCP server: How these become callable by the LLM.

The Schema Visibility

Schema visibility step utilizes Postgres’ information_schema.columns table to actually fetch column metadata from the database - instead of having to hardcode or dump it out of our database every time the LLM needs to know about what schema structure is available in our data layer.

In pkg/db/postgres.go we create an InspectExposedSchema function that returns a slice of type ColumnMetadata which can eventually be passed into the LLM context window.

package db

import (
    "database/sql"
)

// ColumnMetadata defines a single column in our postgres database
type ColumnMetadata struct {
    TableName  string `json:"table_name"`
    ColumnName string `json:"column_name"`
    DataType   string `json:"data_type"`
}

// InspectExposedSchema reads structural layout data dynamically from the system catalog.
func InspectExposedSchema(db *sql.DB, exposedTables []string) ([]ColumnMetadata, error) {
    query := `
        SELECT table_name, column_name, data_type 
        FROM information_schema.columns 
        WHERE table_schema = 'public' 
        AND table_name = ANY($1)
        ORDER BY table_name, column_name;`

    rows, err := db.Query(query, exposedTables)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var metadata []ColumnMetadata
    for rows.Next() {
        var col ColumnMetadata
        if err := rows.Scan(&col.TableName, &col.ColumnName, &col.DataType); err != nil {
            return nil, err
        }
        metadata = append(metadata, col)
    }

    if err := rows.Err(); err != nil {
        return nil, err
    }

    return metadata, nil
}

In the project we’ve setup a .env file with the following variable:

EXPOSED_TABLES=compounds,sales_ledger

This variable is read and passed into the InspectExposedSchema function to fetch only those tables that we’ve explicitly whitelisted for visibility.

It’s worth dwelling on why this is a deny-by-default allowlist rather than an exposed-by-default filter.

A more generic approach would remove the filter entirely, but in a regulated FinTech or real estate platform, that's not a hypothetical risk. Staging tables, audit logs, or a users table with national ID numbers would become visible to the orchestrator the moment they're created, with zero code change and zero review. The allowlist isn't extra friction, it's the only thing standing between "the LLM sees what we intended" and "the LLM sees whatever the last migration happened to leave lying around.”

Important note on the choice of environment variables in this article:

In this article we’re only highlighting a single filter level (table level). But a more production-ready design would include a deeper deny list on a more granular level for columns such as surrogate keys, create/delete/update timestamps or vector fields if you’re using PGVector.

Aggregation

Raw query access is the obvious approach — and the wrong one. Here's why the gateway pre-defines every computation the LLM is allowed to run. For this project, we are taking on one business case where the user of the LLM needs an aggregate of the total number of units sold (units_sold), total revenue made (revenue_egp) and total cancelled orders (cancelled_orders) for a specific region

In the schema provided in the repository, we have 2 entities compounds and sales_ledger . sales_ledger column compound_id is a foreign key that references compounds.id .

In many popular MCP implementations, the LLM would generally create the aggregation query and send it as plain-text for execution. This poses massive security risk - aside from DELETE or DROP statements which are naive assumptions given a read-only access. The real risk is an exhaustive SELECT query. There is no telling what the LLM might decide is the best path. For the majority of cases it might send the correct query for the business need directly.

-- Find aggregate of units sold, revenue, cancelled orders 
-- relative to a select region
SELECT compounds.region, 
        sum(units_sold) AS TOTAL_UNITS_SOLD,
    sum(revenue_egp) AS TOTAL_REVENUE, 
    sum(cancelled_orders) AS TOTAL_CANCELLED
FROM sales_ledger JOIN compounds ON sales_ledger.compound_id = compounds.id
WHERE compounds.region = ANY($1)
GROUP BY compounds.region

But if an attacker were to hijack a session or acquire access to the server running the LLM, there is no stopping them from instructing or injecting a prefix to the context window that instructs the LLM to pull raw data to the server and process it instead of aggregate it.

A more secure gateway only allows the LLM to know what it must know - without any possibility of further hijacking.

In pkg/db/queries.go we initialize a Queries struct and constructor for it which accepts a *sql.DB connection:

type Queries struct {
    db *sql.DB
}

func NewQueries(db *sql.DB) *Queries {
    return &Queries{
        db: db,
    }
}

Then we create the result struct for the first type of aggregation which consists of all the fields that represent a single record out from the above query.

type RegionalMetricsResult struct {
    Region          string  `json:"region"`
    UnitsSold       int     `json:"units_sold"`
    TotalRevenue    float64 `json:"total_revenue"`
    CancelledOrders int     `json:"cancelled_orders"`
}

Finally, we create FindRegionalMetrics method on Queries struct with a pointer receiver:

func (q *Queries) FindRegionalMetrics(ctx context.Context, regions []string) ([]RegionalMetricsResult, error) {
    query := `SELECT compounds.region, 
                         sum(units_sold) AS TOTAL_UNITS_SOLD,
                             sum(revenue_egp) AS TOTAL_REVENUE, 
                             sum(cancelled_orders) AS TOTAL_CANCELLED
                FROM sales_ledger JOIN compounds ON sales_ledger.compound_id = compounds.id
                WHERE compounds.region = ANY($1)
                GROUP BY compounds.region`

    rows, err := q.db.QueryContext(ctx, query, pq.Array(regions))

    if err != nil {
        return nil, err
    }

    defer rows.Close()

    var result []RegionalMetricsResult

    for rows.Next() {
        var col RegionalMetricsResult
        if err := rows.Scan(&col.Region, &col.UnitsSold, &col.TotalRevenue, &col.CancelledOrders); err != nil {
            return nil, err
        }

        result = append(result, col)
    }

    if err := rows.Err(); err != nil {
        return nil, err
    }

    return result, nil
}

pq.Array is required here because Go's database/sql doesn't natively serialize a string slice to Postgres's ANY($1) array syntax - the lib/pq driver wrapper handles that translation.

The FindRegionalMetrics and any similar method absolutely doesn’t have to know about who is calling it. It doesn’t care if the caller is an MCP server or a CRUD API server. It is pure business logic that constricts and abstracts flow from the underlying data store, essentially telling the LLM what it is allowed to do with the data.

This is also true in case your team decides to create a more complex and dynamic aggregate implementation - The end goal remains the same: You give the LLM a sparse set of information proxies that cannot be abused even if an attacker gains access.

Registering the functions as MCP Tools

Now comes the part where we register these tools as discoverable and usable utilities to the LLM.

For this project, we are using github.com/mark3labs/mcp-go to register MCP tools and run the MCP server.

First, we define a small helper that serializes any result type to indented JSON before returning it to the MCP transport layer. Using any as the input type means this same function works for every tool response — schema metadata, regional metrics, or any future query result.

func formatResult(v any) string {
    b, _ := json.MarshalIndent(v, "", "  ")
    return string(b)
}

In production, the marshal error should be handled explicitly. For this gateway, marshaling failures on known struct types are effectively impossible, but the pattern should be hardened before shipping.

The library makes it easy to add a descriptor for the tools using the mcp.NewToolmethod.

For the list_tables tool - initialize a tool name and the description:

    listTablesTool := mcp.NewTool("list_tables",
        mcp.WithDescription("Lists all available database schemas and field structures without exposing raw database records."),
    )

Then use the AddTool method to actually make the tool usable and utilize the InspectExposedSchema function we created above:

    s.AddTool(listTablesTool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
        cols, err := db.InspectExposedSchema(database, exposedTables)
        if err != nil {
            return mcp.NewToolResultError(fmt.Sprintf("Failed to map system constraints: %s", err.Error())), nil
        }

        return mcp.NewToolResultText(formatResult(cols)), nil
    })

The first line of the function has 2 important things to note:

     cols, err := db.InspectExposedSchema(database, exposedTables)

database is a variable holding the *sql.DB instance.

exposedTables is the largely configurable .env EXPOSED_TABLES variable we introduced earlier. This tells the InspectExposedSchema to only pull the information for the explicitly allowed tables.

Next, comes the aggregate method registration. First, initialize the Queries struct:

    queries := db.NewQueries(database)

The FindRegionalMetrics expects a slice of strings for its second argument regions []string . The get_metrics MCP tool can be configured in the mcp.NewTool method to annotate that this tool requires a string slice:

    metricsTool := mcp.NewTool("get_metrics",
        mcp.WithDescription("Retrieves metrics for specified geographical regions"),

        // Define your slice parameter here
        mcp.WithArray("region",
            mcp.Required(), // <-- This marks the parameter as required in the JSON Schema
            mcp.Description("A list of regions to filter metrics by (e.g. ['New Cairo', 'North Coast'])"),
        ),
    )

The mcp.WithArray tells the MCP server to expect a json array.

Next add the tool:

    s.AddTool(metricsTool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
        regions, err := request.RequireStringSlice("region")
        if err != nil {
            return mcp.NewToolResultError(err.Error()), nil
        }

        result, err := queries.FindRegionalMetrics(ctx, regions)
        if err != nil {
            return mcp.NewToolResultError(err.Error()), nil
        }

        return mcp.NewToolResultText(formatResult(result)), nil
    })

The first line:

        regions, err := request.RequireStringSlice("region")

Is important because in the tool description, we only hinted at providing an Array . This method request.RequireStringSliceenforces a typed Array translating to a go StringSlice .

As covered in the previous section, pq.Array handles the Go-to-Postgres array serialization that database/sql doesn't provide natively.

The MCP server now exposes exactly two tools - no more, no less. The LLM can discover what exists and compute what's permitted. Everything else in the database remains invisible.

Wiring it all Together

Now to see the entire structure come to life, we wire together all that was built above into an entrypoint.

As mentioned previously we’re using github.com/mark3labs/mcp-go to spin up an MCP server instead of building one from scratch.

In this project the main.go is located in a standard path cmd/gateway/main.go . The full main.go looks like this:

package main

import (
    "context"
    "database/sql"
    "encoding/json"
    "fmt"
    "log"
    "mcp-postgres-gateway/pkg/db"
    "os"
    "strings"

    "github.com/joho/godotenv"
    _ "github.com/lib/pq" // CRITICAL: Must be explicitly imported here to register the driver
    "github.com/mark3labs/mcp-go/mcp"
    "github.com/mark3labs/mcp-go/server"
)

func formatResult(v any) string {
    b, _ := json.MarshalIndent(v, "", "  ")
    return string(b)
}

func main() {
    err := godotenv.Load(".env")
    // Initialize Postgres Connection
    connStr := os.Getenv("DATABASE_URL")

    exposedTables := strings.Split(os.Getenv("EXPOSED_TABLES"), ",")
    if len(exposedTables) == 0 {
        log.Fatal("EXPOSED_TABLES environment variable is not set")
    }

    if connStr == "" {
        log.Fatal("DATABASE_URL environment variable is not set")
    }

    database, err := sql.Open("postgres", connStr)
    if err != nil {
        log.Fatalf("Database initialization failure: %v", err)
    }
    defer database.Close()

    // Establish the MCP Core Server Block
    s := server.NewMCPServer("domainai-gateway", "1.0.0")

    // 1. Tool 1 Implementation: Expose Schema Table Information
    listTablesTool := mcp.NewTool("list_tables",
        mcp.WithDescription("Lists all available database schemas and field structures without exposing raw database records."),
    )

    s.AddTool(listTablesTool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
        cols, err := db.InspectExposedSchema(database, exposedTables)
        if err != nil {
            return mcp.NewToolResultError(fmt.Sprintf("Failed to map system constraints: %s", err.Error())), nil
        }

        return mcp.NewToolResultText(formatResult(cols)), nil
    })

    // Data tools
    queries := db.NewQueries(database)

    metricsTool := mcp.NewTool("get_metrics",
        mcp.WithDescription("Retrieves metrics for specified geographical regions"),

        // Define your slice parameter here
        mcp.WithArray("region",
            mcp.Required(), // <-- This marks the parameter as required in the JSON Schema
            mcp.Description("A list of regions to filter metrics by (e.g. ['US', 'EU'])"),
        ),
    )

    s.AddTool(metricsTool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
        regions, err := request.RequireStringSlice("region")
        if err != nil {
            return mcp.NewToolResultError(err.Error()), nil
        }

        result, err := queries.FindRegionalMetrics(ctx, regions)
        if err != nil {
            return mcp.NewToolResultError(err.Error()), nil
        }

        return mcp.NewToolResultText(formatResult(result)), nil
    })

    // Start the Server to communicate natively over standard IO channels
    log.Println("MCP Gateway initialized. Establishing communication channel over Stdio...")
    if err := server.ServeStdio(s); err != nil {
        fmt.Fprintf(os.Stderr, "Server crash anomaly: %v\n", err)
        os.Exit(1)
    }
}

In this implementation, .env loading failures are intentionally non-fatal. The application falls back to system environment variables, which is the correct behavior in containerized deployments where .env files aren't present.

Notice how we must import github.com/lib/pq using alias _ for side effects. Once registered database/sql knows exactly how to handle the postgres protocol behind the scenes when you initialize a connection.

Also notice this block of code:

    connStr := os.Getenv("DATABASE_URL")

    exposedTables := strings.Split(os.Getenv("EXPOSED_TABLES"), ",")
    if len(exposedTables) == 0 {
        log.Fatal("EXPOSED_TABLES environment variable is not set")
    }

    if connStr == "" {
        log.Fatal("DATABASE_URL environment variable is not set")
    }

The application deliberately terminates the program if DATABASE_URL is not found in environment. But more notably this pattern is also enforced early in the program when no EXPOSED_TABLES are set. This can be helpful to save network resources and give an early failure signal if your MCP server communicates with the database service across another network or if the database service is a microservice in your ecosystem.

To test the MCP service, you can spin up a quick, on demand MCP inspector UI in your browser by running this npx command:

npx -y @modelcontextprotocol/inspector go run cmd/gateway/main.go

This should open up an MCP inspector tab in your browser.

Test the tools

Running list_tables tool should yield an output similar to this:

[
  {
    "table_name": "compounds",
    "column_name": "developer",
    "data_type": "character varying"
  },
  {
    "table_name": "compounds",
    "column_name": "id",
    "data_type": "integer"
  },
  {
    "table_name": "compounds",
    "column_name": "launch_year",
    "data_type": "integer"
  },
  {
    "table_name": "compounds",
    "column_name": "name",
    "data_type": "character varying"
  },
  {
    "table_name": "compounds",
    "column_name": "region",
    "data_type": "character varying"
  },
  {
    "table_name": "compounds",
    "column_name": "total_units",
    "data_type": "integer"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "cancelled_orders",
    "data_type": "integer"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "compound_id",
    "data_type": "integer"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "id",
    "data_type": "integer"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "quarter",
    "data_type": "character varying"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "revenue_egp",
    "data_type": "numeric"
  },
  {
    "table_name": "sales_ledger",
    "column_name": "units_sold",
    "data_type": "integer"
  }
]

Running the get_metrics tool with the input of ["New Cairo", "North Coast"] Should yield the below aggregated metrics for each region.

[
  {
    "region": "New Cairo",
    "units_sold": 165,
    "total_revenue": 1245000000,
    "cancelled_orders": 3
  },
  {
    "region": "North Coast",
    "units_sold": 12,
    "total_revenue": 180000000,
    "cancelled_orders": 4
  }
]

The LLM received aggregated metrics - totals, not rows. It knows New Cairo sold 165 units. It has no path to the individual transaction records that produced that number. That's the boundary the gateway enforces.

The takeaway

The Go ecosystem is underrepresented in MCP tooling — most implementations lean on Python or TypeScript. But the real gap isn't language choice. It's architectural discipline.

An MCP gateway that lets the LLM construct its own queries is only as secure as the LLM's judgment - and judgment is exactly what attackers exploit. The pattern in this article inverts that assumption: the gateway defines what's computable, the LLM executes within those boundaries, and raw data never crosses the perimeter.

This isn't a limitation of the architecture. It's the feature.

The full implementation is available at khalidelokiely/mcp-postgres-gateway. Clone it, point it at your own Postgres instance, and extend queries.go with the aggregations your business logic actually needs. The schema reflection and transport layer stay unchanged — only the computations you choose to expose are yours to define.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.