Skip to content

v0.19.1

This demo release adds a bounded MCP client slice for the product’s local MCP server and authenticated MCP Gateway discovery.

For a local product-owned MCP server:

ayx headless doctor --server C:\path\to\alteryx-mcp-server.exe
ayx mcp tools list --server C:\path\to\alteryx-mcp-server.exe
ayx mcp tools describe <tool> --server C:\path\to\alteryx-mcp-server.exe
ayx mcp call <tool> --input request.json --server C:\path\to\alteryx-mcp-server.exe

For a published MCP Gateway endpoint, keep the endpoint explicit and provide the bearer token through the environment or standard input:

Terminal window
$env:AYX_MCP_GATEWAY_ENDPOINT = 'https://<gateway>/mcp'
$env:AYX_MCP_GATEWAY_TOKEN = '<token-from-a-secure-secret-store>'
ayx mcp gateway abilities
ayx mcp gateway tools list --family workflow
ayx mcp gateway tools list --family dataset
ayx mcp gateway tools list --family ability

The abilities result reports negotiated MCP capabilities and tool metadata observed from the endpoint. Workflow, dataset, ability, and analytic-app families are metadata-driven; the CLI does not invent product tool names or claim entitlements. Raw tool calls are dry-run by default and require --apply plus the normal confirmation policy to execute.

This is not full parity with the product’s own local MCP server. Product executable discovery and signature validation, curated product workflow/dataset facades, DesignerCore behavior, regional Gateway endpoint/authentication configuration, and product contract fixtures remain follow-up work. The existing direct One workflow commands and XML/engine power lanes remain separate, explicitly labeled backends.

The release candidate is gated by the locked workspace test suite, formatting, clippy, generated command-surface validation, and the existing cross-platform release workflow. The product-host and Gateway live canaries still require an operator with access to the relevant Alteryx environments.