DataPorch

Start here

Build and run

Compile the Go runtime, initialize local secrets, start the HTTP server, and verify its health endpoint.

Connect a database

Import PostgreSQL, SQLite, or MySQL sources through the local admin socket. The MCP surface only sees source IDs.

Wire up an agent

Install the Codex or Claude Code plugin, connect over local stdio MCP, and follow progressive discovery before querying.

The operating model

Agents receive capabilities, source identifiers, metadata, and bounded result sets. DataPorch owns credential handling, validation, authorization, read-only execution, and response limits.

Agent client
    │ dataporch mcp (stdio)
    ▼
local Unix-socket MCP transport
    │ owner-only runtime credential
    ▼
DataPorch MCP handler
    │ validate · authorize · bound
    ▼
execution services
    │ adapter interface
    ▼
PostgreSQL · SQLite · MySQL

The main workflow is progressive and intentionally boring:

data_source.list
  → relational_database.list_schemas
  → relational_database.list_tables
  → relational_database.list_columns
  → relational_database.query

That sequence keeps agents grounded in exact identifiers before they issue a row-producing query.

Direct HTTP clients can use the authenticated /mcp endpoint with an explicit bearer token; bundled plugins use the local stdio path instead.

Read this if you are building

Understand the architecture — module boundaries, composition root, and request flow.
Configure the runtime — every environment variable, default, and validation rule.
Use the MCP tools — inputs, outputs, pagination, and query examples.

Project boundary

DataPorch is the open-source data plane: connectors, tool contracts, validation, bounded execution, local secrets, MCP/API transports, plugin metadata, and skills. A managed control plane—if deployed separately—would own organizations, fleet management, centralized identity, quotas, metering, billing, and audit retention. Those are not prerequisites for running this local runtime.