The StackQL MCP server is now available through every runtime an agent is likely to live in: prebuilt Claude Desktop bundles, npm, PyPI, Docker, a GitHub Action, and the Official MCP Registry. It is the same server in each case - one binary, pulled and launched the way your environment prefers.

What the StackQL MCP server is​

StackQL exposes cloud and SaaS providers - AWS, Google Cloud, Azure, GitHub, Kubernetes, Snowflake, Databricks and more - as a single SQL surface. The MCP server puts that surface in front of an AI agent: the agent discovers providers, services, resources and methods, then runs SELECT queries to read state and (when you allow it) INSERT / UPDATE / DELETE to change it. Reads and writes are gated by a server mode and recorded to an audit log, so "what the agent did" is always answerable.

For background on the protocol itself, see the original StackQL MCP Server Now Available post and the MCP command reference.

One server, every runtime​

Every channel runs the same stackql binary. Pick the one that matches your client:

A typical stdio client config is three lines. For npx:

{ "mcpServers": { "stackql": { "command": "npx", "args": ["-y", "@stackql/mcp-server"] } } }

Swap npx for uvx stackql-mcp-server or docker run -i --rm stackql/stackql-mcp and you have the Python or Docker form. The npm and PyPI launchers download the signed stackql binary on first run, verify its checksum, and share a single cache. The full matrix - including the manual claude_desktop_config.json form for an existing binary - is in Installing the MCP server.

The approvable MCP server​

Letting an agent touch your cloud is a trust decision, so the supply chain is built to be checkable:

• The embedded stackql binary is Authenticode-signed (Windows) and Apple-notarised (macOS).
• Every .mcpb bundle ships with a published SHA-256 checksum on the release page.
• The npm and PyPI launchers verify the downloaded binary's SHA-256 before first use.
• The MCP Registry entry attests the per-platform hashes, so a directory or marketplace can confirm what it is shipping.

On top of the supply chain, the server defaults to mode: safe - reads run freely, mutations and lifecycle operations need approval through the MCP elicitation flow. Pin read_only for inventory agents that should never write, or full_access for trusted automation. See Server modes.

A worked example: cloud audit in CI​

The GitHub Action is where the multi-vector story pays off. stackql/setup-stackql-mcp@v1 installs the binary and writes an MCP config (defaulting to read_only), and anthropics/claude-code-action consumes it through claude_args. The result is an agent that audits your AWS account on every run and files an issue with the SQL it used as evidence:

- id: stackql
  uses: stackql/setup-stackql-mcp@v1
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  with:
    mode: read_only

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: |
      Using the stackql tools, audit our AWS account for: S3 buckets without
      encryption or with public access, security groups open to 0.0.0.0/0 on
      sensitive ports, and IAM users without MFA. Open a GitHub issue
      "Cloud audit <date>" summarising findings WITH the SQL you ran as
      evidence. If nothing is found, do not open an issue.
    claude_args: |
      --mcp-config ${{ steps.stackql.outputs.mcp-config-file }}
      --allowedTools 'mcp__stackql__*'

Because the config is pinned to read_only, the audit can read everything and change nothing - the safety contract is enforced by the server, not by trust in the prompt. The action README has more recipes, including cost estimates on a pull request and a credential-free GitHub inventory.

What the agent actually sees​

Under the hood the agent works the StackQL hierarchy with the same tools whatever the runtime. Pulling the GitHub provider and listing its services looks like this:

> pull_provider {"provider": "github"}
github provider, version 'v26.05.00393' successfully installed

> list_services {"provider": "github"}
actions, activity, apps, billing, checks, code_scanning, codespaces,
copilot, dependabot, gists, git, issues, orgs, packages, projects,
pulls, repos, search, secret_scanning, teams, users, ...

From there the agent can call list_resources and list_methods to discover the required WHERE parameters, then run_select_query to answer a question like "how many public repositories does the stackql org have?" - all without anyone hand-writing SQL.

Get started​

• Install docs for every channel: Installing the MCP server
• Command reference, modes and audit log: stackql mcp
• Registry entry: io.github.stackql/stackql-mcp
• Source and releases: github.com/stackql/stackql

⭐ Star us on GitHub and tell us what your agents build.

Edge defense is a natural fit for an agentic loop: traffic patterns shift constantly, rate-limit thresholds need to follow, and every adjustment should leave an auditable trail. The hard part is usually the plumbing - one API for analytics, another for the rate-limit control plane, another for the durable log.

edgepilot collapses all of that to SQL. Two Claude agents - a recon agent and an action agent - observe a live Cloudflare zone, tighten its rate-limit rule when traffic warrants, and write a decision record to a Confluent Kafka topic. Neither agent knows anything about Cloudflare's GraphQL Analytics API, Cloudflare's rulesets engine, or Confluent's Kafka REST proxy. They know SQL. The StackQL MCP server does the rest.

We've released the latest version of the StackQL Cloudflare provider, including the full Cloudflare V4 API surface under SQL with 108 services, 1259 resources, and 2840 operations.

Service highlights​

Key services in this release include:

Authentication​

Authenticate with a Cloudflare API token via the CLOUDFLARE_API_TOKEN environment variable:

export CLOUDFLARE_API_TOKEN=...

Example queries​

List your zones:

SELECT id, name, status, plan
FROM cloudflare.zones.zones
WHERE account_id = '<account_id>';

Inspect Workers scripts in an account:

SELECT id, modified_on, usage_model
FROM cloudflare.workers.scripts
WHERE account_id = '<account_id>';

List DNS records for a zone:

SELECT name, type, content, ttl, proxied
FROM cloudflare.dns.records
WHERE zone_id = '<zone_id>';

Pull a Radar BGP summary:

SELECT *
FROM cloudflare.radar.bgp_routes_stats;

Binary and non-JSON responses​

A number of Cloudflare endpoints return binary or plain-text payloads - PDF LOAs, PNG screenshots, raw script source, CSV exports. The provider wraps these as a one-row table with a contents column so they're still SELECT-able:

SELECT contents
FROM cloudflare.browser_rendering.screenshot
WHERE account_id = '<account_id>' AND data__url = 'https://example.com';

Get started​

Pull the provider from the public registry:

registry pull cloudflare

Then start querying. Let us know what you build. Star us on GitHub.

We've released an update to the StackQL Confluent provider adding eight new services and 40 additional resources across existing services.

New Services​

The eight new services added in this update are:

Updates​

This release also adds 40 additional resources across existing services, expanding coverage for:

• kafka - additional cluster configuration and topic-level resources
• connect - new connector status, offset, and task management resources
• flink - expanded coverage for Flink statements, compute pools, and artifacts
• iam - new resources for service accounts, identity providers, and role bindings
• networking - additional resources for transit gateways, peerings, and DNS forwarders
• schema_registry - new resources for schema exporters, modes, and compatibility
• billing - new cost and usage resources
• metrics - additional query and descriptor resources

Get Started​

Pull the latest Confluent provider:

stackql registry pull confluent

Visit us on GitHub and let us know how you're using it.

We've released an update to the StackQL GitHub provider adding new services and expanding coverage across several existing ones.

New Services​

Some of the newly added services of note include:

agent_tasks​

The agent_tasks service exposes GitHub's AI agent task API, allowing you to query and manage agent task runs within a repository. Resources include:

This covers the audit and observability side of AI agent operations in GitHub - useful for tracking what agent tasks have run, their status, and step-level output.

campaigns​

The campaigns service covers GitHub's security campaign management, part of GitHub Advanced Security. Resources include:

Security campaigns let you coordinate remediation of code scanning or secret scanning alerts across an org. This service lets you query campaign state and participation programmatically.

classroom​

The classroom service brings GitHub Classroom into StackQL. Resources include:

This is useful for institutions managing GitHub Classroom at scale - querying assignment completion or generating reports across multiple classrooms.

hosted_compute​

The hosted_compute service covers GitHub's hosted compute networking resources, relevant to organizations using GitHub-hosted runners with custom network configurations. Resources include:

This is relevant if you're using GitHub's hosted compute with Azure private networking or similar integrations.

private_registries​

The private_registries service exposes org-level private registry configurations - credentials and settings stored in GitHub for use by Actions workflows. Resources include:

This allows you to audit which private registries (npm, Docker Hub, Maven, etc.) are configured at the org level without going through the GitHub UI.

enterprise_teams​

The enterprise_teams service provides enterprise-scoped team management, distinct from org-level teams. Resources include:

This is useful for enterprises managing teams that span multiple organizations.

Updates​

Notable updates to existing services include:

actions​

New resources added to the actions service:

• hosted_runners - query and manage GitHub-hosted runner configurations at the org or repo level
• runner_group_network_configurations - network config details for runner groups

orgs​

• New org_roles and org_role_assignments resources for querying custom org role definitions and their assignments

repos​

• New repo_rules_suites resource for querying rule suite evaluation history (useful for auditing branch protection rule evaluations)

Get Started​

Pull the latest GitHub provider:

stackql registry pull github

Visit us on GitHub and let us know how you're using it.