Give agents the right business vocabulary

Name the metrics, fields, joins, and filters your team trusts. Then people and agents can ask for revenue, customers, or usage without guessing how your tables work.

Read the docs

Name what matters

Give business concepts a home

Define the fields and metrics your team already talks about — revenue, order count, status, customer, usage — and keep those definitions in config instead of repeating them in every prompt or query.

pawrly.yaml

semantic:
  models:
    - name: orders
      source: data.orders
      primary_key: [id]
      dimensions:
        - { name: status,     expr: status,     type: string }
        - { name: order_date, expr: ordered_at, type: time,
            grains: [day, week, month, quarter, year] }
      measures:
        - { name: order_count,  agg: count_distinct, expr: id }
        - { name: revenue,      agg: sum, expr: total_amount }
        - { name: paid_revenue, agg: sum, expr: total_amount,
            filters: ["status = 'paid'"] }

Ask clearly

Ask for metrics, not table plumbing

People and agents can ask for revenue by status or order count by month without knowing the raw table layout. Pawrly turns those approved names into the SQL needed to answer the question.

pawrly semantic

pawrly semantic query orders.revenue orders.order_count \
  --by orders.status \
  --by orders.order_date.month \
  --where 'orders.status = paid' \
  --order-by orders.revenue:desc

Guarded

Block bad answers before they ship

Some joins look reasonable but quietly double-count revenue or usage. Pawrly can block those queries before an agent turns a bad number into a confident answer.

Required filters travel with the model too, so customer, tenant, or workspace boundaries are applied every time the metric is queried.

guardrails

# This join would double-count revenue,
# so Pawrly blocks it instead of guessing.
pawrly semantic query orders.revenue --by order_items.sku
 
# Required filters are applied every time.
pawrly semantic query orders.revenue --by orders.status \
  --param tenant_id=acme

Fast

Speed up common questions

For metrics people ask about often, define a prepared rollup once. Pawrly can answer matching questions from the faster saved result and fall back to the source data when it needs the full detail.

pre_aggregations

pre_aggregations:
  - name: daily_by_status
    dimensions: [order_date.day, status]
    measures:   [revenue, order_count]
    refresh:    1h
    partition_by: order_date.month

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 GitHub Read the docs