How CloudQuery Works With AI Agents and MCP

Updated

CloudQuery gives AI agents a live SQL query interface to your cloud estate by acting as an MCP (Model Context Protocol) server backed by data you've already synced into your own database. Instead of building a custom integration for each agent, you point Claude, Copilot, or an internal agent at the CloudQuery MCP server, and it queries your infrastructure data directly. This works if you've completed a sync into a supported destination like PostgreSQL or Snowflake — the MCP layer sits on top of that synced data, not on top of raw provider APIs.

The core mechanism: synced data becomes agent context

CloudQuery is described as an open-source, self-hosted tool that syncs 80+ cloud and SaaS sources into your own database. The AI-agent story builds on that existing pipeline rather than replacing it:

  1. Sync — CloudQuery pulls data from sources like AWS, GCP, Azure, GitHub, and Okta into a destination database you operate (Postgres, BigQuery, Snowflake, or S3).
  2. Normalize — All sources land in the same relational shape, so an agent reasons over one schema instead of 80 different raw APIs.
  3. Expose via MCP — The CloudQuery MCP server, running in PostgreSQL or Snowflake Mode, gives any agent a live query interface into that synced data.

The key point: the agent queries your cloud estate directly through SQL, with no bespoke integration to build or maintain.

What "MCP-native" actually means here

MCP (Model Context Protocol) is the interface standard that lets an AI agent call external tools and data sources. CloudQuery being MCP-native means it exposes your synced infrastructure data as an MCP server, so compatible agents can query it without custom glue code.

According to the site, you can point Claude, Copilot, or an internal agent at the CloudQuery MCP server. The server is backed by your synced data in PostgreSQL or Snowflake Mode. Because the data is already normalized into one relational schema, the agent gets a consistent shape to reason over across all 80+ sources.

Why one normalized schema matters for agents

Most DIY approaches end up with a separate exporter or script per provider, and each tool has its own query language or dashboard filters. For an AI agent, that fragmentation is a real problem: the agent would need to know 80 different APIs and query dialects.

CloudQuery collapses this into a single relational schema. The practical effect for an agent is:

Concern DIY scripts & exporters With CloudQuery
Source coverage A separate script per cloud/SaaS source One tool syncs 80+ sources
Querying Each tool has its own language or filters Standard SQL, no proprietary language
Data control Credentials and data spread across tools Self-hosted; data stays in your network unless you choose otherwise
Versioning No version history or single source of truth Every sync defined in version-controlled YAML, reviewed in PRs
Scale Scans slow down or time out as accounts grow Incremental sync keeps scans across hundreds of accounts fast

For an agent, the normalized schema plus standard SQL means it can answer questions across providers without per-provider logic.

What you need before an agent can query

The MCP layer depends on a completed sync, so the prerequisites are:

  • CloudQuery installed — a single binary on Linux, macOS, or Windows. Install options include Homebrew (brew install cloudquery/tap/cloudquery), a shell script (curl -fsSL https://cloudquery.io/install.sh | sh), or Docker.
  • Sources defined in YAML — point at the cloud providers and SaaS apps you want.
  • A destination database you already operate — Postgres, BigQuery, Snowflake, or S3.
  • A sync run — once, or on a schedule in your pipeline — so data lands in the destination.
  • The MCP server — running in PostgreSQL or Snowflake Mode, backed by that synced data.

If you're missing a source, the site notes you can build it with the SDK.

A concrete example

Say your team syncs AWS, GCP, GitHub, and Okta into Snowflake. An internal agent needs to answer: "Which repositories have deploy access from accounts without MFA enforced?"

Without CloudQuery, you'd wire the agent to four separate APIs with four auth models and four data shapes. With CloudQuery, the agent queries the MCP server in Snowflake Mode using SQL against the already-normalized tables — one query surface, one schema, no bespoke integration.

Where this fits and where it doesn't

This setup suits teams that already run CloudQuery syncs and want to reuse that infrastructure data as a context layer for AI agents. It's self-hosted, so data control stays with you.

It's less relevant if you haven't set up a sync yet — the MCP server needs synced data in a supported destination to function. And since the site lists a "Free" heading and a pricing page, check the pricing page directly for current plan details rather than assuming what's included.