7 posts tagged with "claude"

We've released an update to the StackQL anthropic provider, regenerated from the current Claude API specification. The provider now covers 12 services, 27 resources and 108 operations (up from 11, 26 and 103 in the July release). Changes in this release:

• A new dreams service
• Files and skills moved to their generally available endpoints
• Workspace-scoped queries on most operations through the anthropic-workspace-id parameter

The anthropic_admin provider (6 services, 11 resources, 27 operations) is unchanged in this release.

Dreams​

Dreams are asynchronous memory-consolidation jobs: a dream reads a memory store and a set of session transcripts and writes consolidated memories into an output store. The service is a research preview on the Anthropic side, so the endpoints return a 404 for keys that are not enrolled. The dreams resource maps the surface as follows:

Dreams and their status as rows:

SELECT id, status, JSON_ARRAY_LENGTH(inputs) AS input_count, created_at, ended_at
FROM anthropic.dreams.dreams
ORDER BY created_at DESC;

Starting one is an INSERT. inputs and model are JSON values that the provider passes through as structured request fields:

INSERT INTO anthropic.dreams.dreams (inputs, model, instructions)
SELECT '[{"type": "memory_store", "memory_store_id": "memstore_01..."}]',
       '{"id": "claude-opus-5"}',
       'Consolidate project decisions and open questions.'
RETURNING id, status;

Files and skills on GA endpoints​

The Files API and the Skills API are generally available. The files and skills services now call the GA endpoints (/v1/files, /v1/skills) instead of the beta ones, and no longer send an anthropic-beta header. Resources, methods and SQL verbs are unchanged, so existing queries keep working. One behavioural change: the files list is now cursor-paginated and the provider walks the pages automatically.

SELECT id, filename, mime_type, size_bytes, created_at
FROM anthropic.files.files
ORDER BY created_at DESC;

SELECT id, display_name, JSON_EXTRACT(source, '$.type') AS source, latest_version_id, updated_at
FROM anthropic.skills.skills
ORDER BY updated_at DESC;

Skill versions are a separate resource keyed by the skill:

SELECT id, skill_id, name, description, created_at
FROM anthropic.skills.versions
WHERE skill_id = 'xlsx';

Uploading a file or creating a skill version is a multipart request, which SQL cannot express; those two methods remain documented as EXEC operations, and the rest of each resource (list, get, delete) is plain SQL.

Workspace-scoped queries​

The Claude API added an optional anthropic-workspace-id header to most operations, for credentials that can act on more than one workspace. The provider exposes it as an optional parameter on around 110 operations. It is a hyphenated name, so it is double-quoted in SQL:

SELECT id, display_name, created_at
FROM anthropic.models.models
WHERE "anthropic-workspace-id" = 'wrkspc_01CZkZaBF1tNoB5wlCeusgy';

The workspace ids are the ones the anthropic_admin provider lists:

SELECT id, name, archived_at
FROM anthropic_admin.workspaces.workspaces;

A key that belongs to a single workspace can omit the parameter. The API validates the value: a malformed id is rejected with a 400.

Under the hood​

The provider is generated from the OpenAPI specification that Anthropic now bundles with its SDKs. That specification grew from 126 to 244 operations since July, and the SDKs' configured endpoint count from 116 to 201. Beyond the changes above, the growth is the beta twins of the GA files and skills endpoints and the Admin API, which the specification now models but which needs an org-scoped admin key and belongs to the anthropic_admin provider. Every operation in the specification is either mapped or listed in a documented exclusion list, and the build fails when the two do not add up.

Every documented example query runs in the provider's test suite, and each generated docs page now shows the date it was last regenerated.

Authentication​

Unchanged. The two providers use different key types, which are disjoint by design:

# anthropic - workspace-scoped Claude API key
export ANTHROPIC_API_KEY=sk-ant-api...

# anthropic_admin - org-scoped Admin API key (created by org admins)
export ANTHROPIC_ADMIN_KEY=sk-ant-admin...

Get started​

Pull the latest provider from the public registry:

registry pull anthropic;

Provider docs, including required parameters and example queries for every resource, are at anthropic-provider.stackql.io and anthropic-admin-provider.stackql.io. Visit us on GitHub and let us know how you're using it.

We've released an update to the StackQL providers for the Anthropic platform:

• anthropic - the Claude API surface: messages, models, batches, files, agents, deployments, environments, sessions, skills, memory stores, user profiles, and vaults (11 services, 26 resources, 103 operations)
• anthropic_admin [new] - the Admin API surface: organization, users, invites, workspaces, API keys, usage and cost reports, rate limits, and Claude Code analytics (6 services, 11 resources)

Both providers expose a SQL-first surface: authentication is handled automatically, Push down support using the LIMIT clause and built in pagination handling.

Inference as a query​

Inference using Claude is accessible via SELECT for instance:

SELECT
id,
model,
stop_reason,
JSON_EXTRACT(content, '$[0].text') AS assistant_message,
JSON_EXTRACT(usage, '$.output_tokens') AS output_tokens
FROM anthropic.messages.messages
WHERE model = 'claude-sonnet-5'
AND max_tokens = 2048
AND messages = '[
  {
    "role": "user",
    "content": "how does stackql work?"
  }
]'
AND system = 'You are a technical assistant. Answer in one short paragraph.'
AND thinking = '{"type": "disabled"}';

Token counting works the same way via anthropic.messages.token_counts - free of charge.

Model capabilities view​

The provider ships a convenience view that fans the per-model capability matrix out of the capabilities JSON column into flat columns:

SELECT id, display_name, thinking, adaptive, xhigh, max_input_tokens, max_tokens
FROM anthropic.models.vw_model_capabilities;

One row per model with boolean flags for batch, citations, code execution, context management, effort tiers (low through xhigh), image and PDF input, structured outputs, and thinking modes - useful for picking a model programmatically instead of reading release notes.

The admin provider - your Anthropic org as data​

The anthropic_admin provider presents the organization management surface as SQL.

Enumerate workspaces and who's in them:

SELECT id, name, created_at, data_residency
FROM anthropic_admin.workspaces.workspaces;

SELECT user_id, workspace_id, workspace_role
FROM anthropic_admin.workspaces.members
WHERE workspace_id = '<workspace_id>';

Audit users and API keys across the org:

SELECT id, email, name, role
FROM anthropic_admin.organization.users;

SELECT id, name, status, workspace_id, partial_key_hint
FROM anthropic_admin.api_keys.api_keys;

Pull usage reports as time-bucketed rows - results is a JSON column you can break down with JSON_EACH, and reports can be grouped and filtered by model, workspace, API key, service tier, and more:

SELECT starting_at, ending_at, results
FROM anthropic_admin.usage.usage_reports
WHERE starting_at = '2026-07-01T00:00:00Z'
AND "group_by[]" = 'model';

Cost reporting and Claude Code adoption analytics work the same way:

SELECT starting_at, ending_at, results
FROM anthropic_admin.cost.cost_reports
WHERE starting_at = '2026-07-01T00:00:00Z';

SELECT starting_at, ending_at, results
FROM anthropic_admin.usage.claude_code_reports
WHERE starting_at = '2026-07-01T00:00:00Z';

Because it's all SQL, you can join usage to workspaces, materialize daily cost snapshots into a database, or point a BI tool at StackQL's Postgres wire protocol server and build an org-wide Claude spend dashboard without writing a line of integration code.

Authentication​

The two providers use different key types, which are disjoint by design:

# anthropic - workspace-scoped Claude API key
export ANTHROPIC_API_KEY=sk-ant-api...

# anthropic_admin - org-scoped Admin API key (created by org admins)
export ANTHROPIC_ADMIN_KEY=sk-ant-admin...

Admin keys are available to organization accounts only and can be provisioned by users with the admin role in the Console.

Get started​

Pull the providers from the public registry:

registry pull anthropic
registry pull anthropic_admin

Provider docs are at anthropic-provider.stackql.io and anthropic-admin-provider.stackql.io. Let us know what you build. Star us on GitHub.

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.

We've published a Claude Skill for StackQL provider development. It provides Claude with the context needed to help you build providers using the any-sdk library (interface used by StackQL to interact with the cloud providers).

What's in the Skill​

The skill covers the full provider development workflow:

• Provider document structure - The provider.yaml schema and service document layout
• OpenAPI extensions - All x-stackQL-* extensions including x-stackQL-resources, x-stackQL-config, x-stackQL-objectKey, and others
• Resource and method definitions - How to define resources, map methods to operations, and configure responses
• SQL verb mappings - Connecting REST operations to SELECT, INSERT, UPDATE, and DELETE
• Authentication patterns - API keys, service accounts, OAuth, and custom auth schemes
• Pagination handling - Request/response token configuration
• Response processing - JSONPath extraction, transformations, and schema handling

Download​

Grab the skill from the any-sdk repository:

Download stackql-provider-development.md

Usage​

With the skill loaded, you can ask Claude things like:

• "Create a provider definition for this API"
• "How do I map this endpoint to a SELECT operation?"
• "What's the correct objectKey syntax for this nested response?"
• "Help me configure pagination for this API"

Claude will have the full context of StackQL's OpenAPI extensions and provider patterns to work from.

Example​

Here's a sample interaction after loading the skill:

You: I have an API endpoint GET /users that returns {"data": {"users": [...]}}. 
     How do I set up the resource?

Claude: For that response structure, you'd configure the method like this:

methods:
  list:
    operation:
      $ref: '#/paths/~1users/get'
    response:
      mediaType: application/json
      openAPIDocKey: '200'
      objectKey: $.data.users

The objectKey uses JSONPath to extract the users array from the nested response.

Resources​

• StackQL Provider Registry
• any-sdk documentation
• StackQL documentation

⭐ Star us on GitHub