NewAgents need a query surface, not more tools

One SQL interface for APIs.

Connect the APIs, files, MCP servers, and databases your team already uses. Pawrly gives them table names, columns, and joins, so people and agents can ask one SQL question instead of stitching together data from multiple sources.

Read the docs

Local SQL runtime over your APIs, files, and MCP servers for agents

One interface over the data your work already lives in

Stripe·Postgres·Snowflake·S3·Iceberg·GraphQL·OpenAPI·Linear·DuckDB·Parquet·MySQL·Delta·Notion·Intercom·GCS·DuckLake·Stripe·Postgres·Snowflake·S3·Iceberg·GraphQL·OpenAPI·Linear·DuckDB·Parquet·MySQL·Delta·Notion·Intercom·GCS·DuckLake·
How it works

Describe each source once. Query it as SQL forever.

Add the source to pawrly.yaml, give the fields clear names, and query it like a table. The next person, script, or agent uses the same names without learning another API.

pawrly.yaml
version: 1
name: my-workspace
secrets:
  - kind: env
 
sources:
  - name: stripe
    kind: http
    config:
      base_url: https://api.stripe.com
      auth:
        type: header
        headers:
          - name: Authorization
            bearer: ${secret:STRIPE_API_KEY}
    tables:
      - name: customers
        endpoint: /v1/customers
        response:
          path: $.data
          schema:
            - { name: email,      type: varchar }
            - { name: name,       type: varchar }
            - { name: delinquent, type: bool }
 
  - name: intercom
    kind: http
    config:
      base_url: https://api.intercom.io
      auth:
        type: header
        headers:
          - name: Authorization
            bearer: ${secret:INTERCOM_TOKEN}
    tables:
      - name: contacts
        endpoint: /contacts
        response:
          path: $.data
          schema:
            - { name: email,        type: varchar }
            - { name: last_seen_at, type: bigint }
pawrly sql
SELECT c.email, c.name, i.last_seen_at
FROM stripe.customers c
JOIN intercom.contacts i
  ON i.email = c.email
WHERE c.delinquent = false
ORDER BY i.last_seen_at ASC;
emailnamelast_seen_at
ava@northwind.coAva Chen41 days ago
sam@globex.ioSam Okoye33 days ago
lin@initech.devLin Park29 days ago

— Stripe × Intercom · 3 rows · 84ms

— semantic hints applied · hot path cached

Run the same query from the CLI, an MCP client, or a long-running pawrly serve process. The interface stays the same, so a query that works locally is the one an agent uses later.

Sources

Query the data where it already lives.

Bring Stripe, CSVs, Linear, internal MCP servers, and Postgres into the same SQL question. Pawrly handles the source details so the query can focus on the answer.

APIs

Give Pawrly an endpoint or OpenAPI spec, then read the response as rows and columns.

RESTGraphQLOpenAPI 3.0StripeIntercomHubSpot

Files & Object Storage

Read Parquet, CSV, and JSON from disk or a bucket without loading them into a warehouse first.

ParquetCSVJSONS3GCSAzure

MCP Servers

Connect to MCP servers like Linear, GitHub, Notion, and internal tools and query their outputs as rows.

LinearGitHubNotionAny MCP server

Databases

Join operational tables with APIs, files, and warehouse data from the same query.

PostgresMySQLSQLiteDuckDB

Warehouses & Lakehouses

Use existing warehouse and lakehouse data beside live sources, without building a pipeline first.

SnowflakeIcebergDeltaDuckLake
For agents

Stop making agents write glue code.

When an agent needs customer context, it should ask for the answer, not write a mini integration. Pawrly keeps the source setup in one place and gives the agent approved tables to query.

One place to ask

Instead of handing an agent a different tool for every system, give it approved tables it can query with SQL.

Same names every time

Sources are declared once. Every agent sees the same tables and columns, and every query can be logged, replayed, and reviewed.

Works with MCP

Connect Pawrly to Claude Desktop, Cursor, Codex, or other MCP clients, and let those clients query the same workspace.

connect any MCP client
pawrly mcp-stdio --config ./pawrly.yaml

“Find paying customers support hasn't heard from in a month.”

Pawrly turns that into a join across Stripe and Intercom. The agent asks for the customers, Pawrly handles the source details, and the query is there to review afterward.

Governed, not just connected

Answers you can review.

Give important fields approved names, define which joins are allowed, and keep required filters attached to the data. Agents get useful access without direct access to every system.

01

Bad joins fail loudly

If a join would double-count a metric, Pawrly stops the query instead of returning a polished wrong answer.

02

Access rules travel with the data

Required filters are applied every time, whether the query comes from a person, script, or agent.

03

Rules are visible up front

Agents can inspect the available tables, fields, joins, and required filters before they write a query.

Writing

Why we're building Pawrly

All posts
July 9, 2026 / 13 min read

SQL Code Mode for MCP

Today, most MCP servers expose one tool per operation, so you end up with tools like getcustomers, getordersbycustomer, getticketcounts, searchissues, and listpullrequests. That…

ReadJune 23, 2026 / 7 min read

How to Query Any API with SQL

Most useful business data does not live in one warehouse.

ReadJune 21, 2026 / 5 min read

Agents Need a Query Surface, Not More Tools

I keep coming back to the same problem with agents.

Read

One binary. One config. Every source.

Start with one config file, then query APIs, files, MCP servers, and databases from the same command. Add MCP when you want agents to use that same workspace.

Star on GitHubRead the docs