StackQL v0.11 is out. The StackQL MCP server: now includes the current Model Context Protocol revision, 2026-07-28, alongside every earlier revision it already supported, and the audit log that records what an agent did can be written as OpenTelemetry log records instead of the bespoke JSONL format. Both are available today through every install channel.

The StackQL MCP server has been reviewed by Anthropic and is now listed in the Anthropic MCP Directory. StackQL is a member of the Claude Partner Network, and the directory listing makes the MCP server discoverable and installable directly from within Claude Desktop - no manual bundle download, no custom connector configuration.

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.

stackql-deploy 2.0 is a full rewrite in Rust. The Python package (stackql-deploy on PyPi) is archived at 1.9.4. CLI interface and stack file format are unchanged - no migration required.

Why Rust​

The move to Rust was primarily about distribution and operational simplicity. Rust also brings stronger guarantees around performance and memory safety. Running everything in-process without Foreign Function Interface (FFI) boundaries simplifies the architecture while maintaining predictable resource usage.

Embedded Postgres Wire Protocol Server​

The most significant functional change in 2.0 is that stackql-deploy now runs the StackQL engine as an embedded in-process server over a local postgres wire protocol connection rather than shelling out to the StackQL binary as an external process.

There is nothing to start, stop, or configure. The server is lifecycle-managed by stackql-deploy itself and binds to localhost only - no port is exposed on the network, no inbound firewall rules needed in CI.

The previous model spawned a new StackQL process per operation. The embedded server keeps a persistent connection for the duration of a deployment run. For stacks with many resources, the reduction in process spawn overhead is noticeable - particularly on Windows where process creation is expensive.

Additional Features Added​

In addition to added the architectural change to use the embedded server, several other workflow improvements were added including:

• Enabling resource scoped variable exports in /*+ exists */ queries: When an exists query returns a named field (e.g. vpc_id) instead of count, the value is captured as a resource-scoped variable (this.vpc_id) and made available to all subsequent queries for that resource (e.g. statecheck, exports). This eliminates the need for redundant lookups to resolve resource identifiers between query stages.
• Support for capturing RETURNING payloads from DML operations: INSERT, UPDATE, and DELETE statements can include a RETURNING clause. Fields from the response can be mapped to resource-scoped variables via return_vals in the manifest, keyed by operation (create, update, delete). This allows identifiers assigned by the provider during creation to be used immediately without a round-trip query.
• Additional template filters: Including the to_aws_tag_filters filter, which converts global_tags to the AWS Resource Groups Tagging API TagFilters format, and type-preserving YAML-to-JSON serialization that maintains string types through the rendering pipeline.
• Improved logging and exception handling: Enhanced visibility simplifying troubleshooting.

Installation​

curl -L https://get-stackql-deploy.io | tar xzf -

Invoke-WebRequest https://get-stackql-deploy.io -OutFile stackql-deploy.zip
Expand-Archive stackql-deploy.zip -DestinationPath .

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
    steps:
      - uses: actions/checkout@v4
      - uses: stackql/stackql-deploy-action@v2
        with:
          command: 'build'
          stack_dir: 'examples/my-stack'
          stack_env: 'prod'
          env_vars: 'GOOGLE_PROJECT=my-project'

      - name: Deploy Stack
        id: stackql-deploy
        uses: stackql/stackql-deploy-action@v2
        with:
          command: 'build'
          stack_dir: 'examples/my-stack'
          stack_env: 'prod'
          output_file: 'deployment-outputs.json'
          env_vars: 'GOOGLE_PROJECT=my-project'

      - name: Use outputs
        run: |
          echo '${{ steps.stackql-deploy.outputs.deployment_outputs }}' | jq .

cargo install stackql-deploy

Usage​

The CLI interface is unchanged from the Python version:

# deploy a stack
stackql-deploy build my-stack prod \
  --e GOOGLE_PROJECT=${GOOGLE_PROJECT}

# test a stack
stackql-deploy test my-stack prod \
  --e GOOGLE_PROJECT=${GOOGLE_PROJECT}

# tear down a stack
stackql-deploy teardown my-stack prod \
  --e GOOGLE_PROJECT=${GOOGLE_PROJECT}

# dry run
stackql-deploy build my-stack prod \
  --e GOOGLE_PROJECT=${GOOGLE_PROJECT} \
  --dry-run

Stack files and stackql_manifest.yml structure are unaffected - no migration work needed.

Python Package Deprecation​

stackql-deploy 1.9.4 on PyPi is the final Python release. The Python source repository is archived. If you have pip install stackql-deploy in any scripts or CI pipelines, replace it with one of the install methods above. The 1.9.4 package remains on PyPi and installable, but will not receive updates.

Links​

• GitHub: github.com/stackql/stackql-deploy
• crates.io: crates.io/crates/stackql-deploy
• StackQL docs: stackql.io/docs

StackQL Studios has joined the Linux Foundation and the Agentic AI Foundation (AAIF) as a Silver Member.

As agentic AI moves from experimentation toward production workloads, we believe the infrastructure layer matters. Open, interoperable standards will be essential for AI agents to work reliably across cloud providers, data platforms, and enterprise systems.

StackQL provides a SQL-based interface for querying, provisioning, and managing cloud infrastructure across providers. Our work on the StackQL MCP Server brings this capability to AI agents through the Model Context Protocol, enabling agents to interact with cloud resources using natural language while maintaining the governance and auditability that production systems require.

Joining AAIF aligns with our long-standing commitment to open-source infrastructure tooling. We look forward to contributing to the foundation's work on MCP, agent runtimes, and the broader ecosystem of standards that will shape how AI agents interact with the systems they manage.

More information about the Agentic AI Foundation is available at aaif.io.