Snowflake MCP adds background agent runs and selective results

Snowflake has added background execution to agent tools in its managed Model Context Protocol server. An MCP client can start a Cortex or Coding Agent job, receive a handle immediately, then check progress, cancel the run or retrieve its answer later. The November 4 release note also introduces selective retrieval, so clients can inspect an answer outline before requesting individual content blocks.

For teams connecting assistants to business data, the useful change is control over the waiting period and the response that comes back. A client can keep a job reference instead of treating one uninterrupted tool call as the entire workflow. It still has to handle failures, approval requests and the final result.

What the Snowflake MCP update changes

The new background argument applies to CORTEX_AGENT_RUN and CODING_AGENT. Setting it to true makes the call return a handle. Servers exposing either type automatically receive ASYNC_AGENT_RUN_STATUS, ASYNC_AGENT_RUN_CANCEL and AGENT_RUN_RESULT. The result tool can read an answer from a synchronous run too.

There is no need to manually add those three helpers to the server specification. Snowflake’s CREATE MCP SERVER reference distinguishes a stored Cortex Agent, identified by its database and schema, from CODING_AGENT, which needs no stored agent object. The coding configuration lives in the server specification, and Snowflake adds its coding toolset to each run.

The practical choice is whether to expose an existing governed business agent or a hosted coding capability. Teams should make that choice before concentrating on asynchronous execution. Moving a task into the background changes how the caller follows the work, not which business workflow the agent should own.

Poll the job, then retrieve only what matters

The managed MCP guide describes a run_id and thread_id in the initial response. Status polling can report in_progress, input_required, completed, cancelled or failed. When the run completes, the client uses AGENT_RUN_RESULT with the same run_id. Cancellation stops an active run; an already finished run returns its current status.

For a long report, content_cel_filter offers compact output by default, full output, or an outline listing each block’s index, type and size. A client can then ask for a table or another specific block using a CEL expression. If the expression fails, Snowflake returns an outline and error rather than silently applying a different filter.

This makes a useful review pattern possible: inspect the outline, retrieve the evidence needed for the question, and request more only when necessary. Smaller returned content should not be mistaken for cheaper agent execution. The agent may already have done the work that produced the full answer.

Background execution still needs approval handling

Snowflake’s Coding Agent documentation describes a hosted sandbox with coding tools, including file operations and SQL. Its default always_ask permission policy stops before state-changing tool calls. An integration needs an approval path that presents the requested operation and sends back the user’s decision.

On the MCP side, input_required is the signal to surface that decision rather than keep polling indefinitely. The response contains pending permissions, and the client resumes through the agent tool. The server does not offer session-wide permission grants in those prompts.

The server reference allows always_allow for trusted automation, but that removes an execution gate. Tool annotations such as readOnlyHint are also only hints, not enforcement. A deployment should use the actual privileges of the underlying objects as its boundary, not a reassuring tool description.

A sensible acceptance test includes a denied operation, a cancelled job and a failed job alongside the successful example. The interface should make these outcomes distinguishable to the person who asked for the work. A spinner that never stops is not an adequate approval workflow.

Availability, access and costs to check

This is an update to an existing service. The managed MCP server reached general availability in November 2025. The new November 4, 2026 note does not announce a separate subscription tier or give the added tools a new preview or GA label.

The underlying Cortex Agents Run API documents background runs as generally available on AWS and Azure, requiring threads and timing out after six hours. Ordinary REST requests time out after 15 minutes. Those are the documented API boundaries, not a promise that every MCP client, region or agent configuration supports the same experience.

Access remains role-based. The agent access guide requires an appropriate Cortex database role, access to the agent and its database and schema, plus privileges on the warehouses and tools it uses. The MCP server itself also needs a separate USAGE grant. Calling an agent does not automatically confer access to everything behind it. Administrators should test the actual calling role, not only an administrator session.

Snowflake’s AI pricing documentation bills Cortex Agents in AI Credits per million tokens, with model-dependent rates and additive costs for underlying services. It lists no per-seat AI fee. AI Credit pricing is consistent across editions, while non-AI warehouse, storage and transfer costs remain separate. Selective output retrieval does not establish a discount on tokens already processed.

Check the protocol before wiring this into production

The managed-server guide still specifies MCP revision 2025-11-25 and a maximum of 50 tools per server. It does not support every MCP construct, including resources, prompts and sampling. Those compatibility limits matter even when the client successfully discovers the agent tools.

Our coverage of the July 2026 MCP protocol update explains the broader move toward a stateless core. Snowflake’s documented revision should be checked separately; this agent-tool update is not evidence that the server has adopted every newer protocol feature.

For an existing Snowflake team, the strongest first use is a bounded task with a clear completion condition, a person responsible for approvals and an answer that can be reviewed in parts. Start by proving that the client preserves job handles and exposes every terminal state. Background execution is useful when the application can explain what happened after the user stopped waiting.