Pylar – Secure MCP Tools for AI Agent Data Governance

TL;DR

TL;DR: Pylar lets you wrap SQL views from Snowflake, Postgres, BigQuery, HubSpot, and Stripe into MCP tools — giving AI agents controlled, observable data access without a custom API layer.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: pylar.ai ← MUST visit and verify
• GitHub: None identified — Pylar is a proprietary SaaS platform with no public source repository verified at time of writing.
• License: Proprietary — no open-source license confirmed.
• HN launch thread: news.ycombinator.com/item?id=46134804 — Show HN, 1 point (2026-07-28).

What Is Pylar?

Pylar is a data governance and MCP (Model Context Protocol) tooling platform for teams running AI agents in production. It sits between AI agents (Cursor, Claude Desktop, LangChain, n8n) and the databases those agents need to query — Snowflake, Postgres, BigQuery, HubSpot, Stripe, and Zendesk.

The core problem it solves: agents need data, but security teams do not want agents connecting directly to production databases. Pylar provides a middle layer where engineers define SQL views (what data is safe to expose), publish them as MCP tools, and get full observability over which agent queries which data when.

From the product page:

“Pylar sits between your agents and your databases. You define what data they can access, build custom tools on top of it, and get full observability across all your AI deployments.”

How It Works

Step 1: Connect Your Data Sources

Pylar connects to a range of data sources out of the box:

• BigQuery
• Postgres (public, billing, support schemas)
• Snowflake (PROD, FINANCE, CS databases)
• HubSpot (contacts, companies, deals)
• Stripe (customers, subscriptions, invoices)
• Zendesk (tickets, users)

Each connection maps to specific databases or schemas, so access boundaries are set at the connection level.

Step 2: Define Views as Access Policies

Rather than granting agents direct table access, engineers define SQL views that surface only the data columns and rows appropriate for agent use. For example, a cs_support view might join customers, tickets, and subscriptions but omit raw payment card data.

These views serve as both the access policy and the query foundation.

Step 3: Publish as MCP Tools

Once a view is validated, Pylar generates an MCP tool specification — including the tool name, a description, parameter types, and the underlying SQL query. Publishing is one click in the UI.

The resulting tool follows the MCP schema:

{
  "name": "get_customer_health",
  "description": "Get customer health status and metrics by email",
  "params": {
    "email": "string"
  },
  "query": "cs_support_by_email(@email)"
}

Agents running in Cursor, VS Code, Claude Desktop, or any MCP-compatible runtime can call this tool directly.

Step 4: Monitor and Control

Pylar provides a query editor, execution logs, and results view per agent session. You can see which tools were called, with what parameters, and what data was returned — giving security and ops teams the observability to audit agent behavior against data access policies.

Practical Evaluation Checklist

• [x] Snowflake, Postgres, BigQuery connections verified from product UI text
• [x] HubSpot, Stripe, Zendesk connections verified from product UI text
• [x] MCP tool schema verified from product UI (JSON example)
• [x] One-click publish workflow described on product page
• [x] Observability / query logs confirmed from product page
• [x] No public GitHub repository identified
• [x] No YC or institutional funding claim found on product page
• [ ] Free tier / pricing confirmed (product page says “Get started free” — specific limits not confirmed)
• [ ] Self-hosted deployment option — not confirmed

Security Model

Pylar’s security posture centers on two ideas:

1. No direct database credentials to agents. Agents never receive connection strings to production databases. They only interact through published MCP tools that Pylar mediates.

2. View-based data masking. By exposing SQL views instead of raw tables, teams can mask sensitive columns (PII, payment data) at the view definition level before any agent ever sees them.

The product page includes a quote from a Head of Engineering at a company that had security concerns about hooking agents directly to Snowflake — which suggests the product’s primary buyer is an enterprise security or compliance team that needs to sign off on AI data access.

Pricing

The product page includes a “Get started free” call to action with a “Talk to us” path for paid plans. Specific free tier limits (number of agents, queries per month, data sources) were not confirmed on the landing page at time of writing.

FAQ

Q: Does Pylar work with Cursor and Claude Desktop? A: Yes. The product page explicitly mentions Cursor, Claude Desktop, and n8n as integration targets. MCP is the protocol layer, so any MCP-compatible agent runtime should work.

Q: Is there a self-hosted option? A: Not confirmed. The product appears to be a hosted SaaS. A self-hosted deployment option was not described on the product page.

Q: What SQL dialects are supported? A: Pylar connects to Snowflake, Postgres, and BigQuery, which use different SQL dialects. The platform abstracts over these — the view definition syntax is the user’s responsibility, but Pylar handles the connection layer for each.

Q: Can I use Pylar without MCP? A: MCP appears to be the primary integration mechanism. The platform is built around publishing tools to MCP, and the agent integrations (Cursor, Claude Desktop, n8n) are all MCP-native.

Conclusion

Pylar addresses a specific, real problem: teams want to run AI agents against production databases, but security and compliance teams need guardrails. The view-based MCP tool approach is a pragmatic middle ground — no custom API layer, no agent credentials to manage, and full observability on every query.

The product is early (Show HN with 1 point, proprietary SaaS, no public source). Whether the free tier is generous enough for individual developers to evaluate and whether the platform scales to enterprise data volumes are questions worth answering before committing to it for a production workload.

If you are running LangChain agents, n8n workflows, or Cursor/CClaude Desktop sessions against live databases today and fielding pushback from your security team, Pylar is worth a look.