NewAgents need a query surface, not more tools

One SQL interface for APIs.

Connect the APIs, files, MCPs 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.

Get startedSee it query

Local SQL runtime over your APIs, files and MCPs for Agents

pawrly sql
-- two live APIs, joined in one statement
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

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: balance, type: bigint }

The vendor already wrote the contract. Point an http source at an OpenAPI 3.0 spec and Pawrly synthesizes one typed table per GET — no hand-written schema needed.

now it's a table
pawrly sql "
  SELECT email, balance
  FROM stripe.customers
  WHERE delinquent = true
"

Run the 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 same query an agent can use later.

Sources

Query the data where it already lives.

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

APIs

table

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

RESTGraphQLOpenAPI 3.0StripeIntercomHubSpot

Files & object storage

table

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

ParquetCSVJSONS3GCSAzure

MCP servers

table

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

LinearGitHubNotionAny MCP server

Databases

table

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

PostgresMySQLSQLiteDuckDB

Warehouses & lakehouses

table

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
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 tools, and databases from the same command. Add MCP when you want agents to use that same workspace.

Star on GitHubRead the docs