Snowflake-managed MCP server adds background runs for Cortex Agents

Snowflake has added background execution to the agent tools of its Snowflake-managed MCP server. According to a Snowflake release note dated November 4, 2026, the CORTEX_AGENT_RUN and CODING_AGENT tool types now accept a boolean argument called background. When a client sets it to true, the tool call returns at once with a run handle, and the agent keeps working on the Snowflake side while the client checks on it later.

The same release adds three tools that Snowflake inserts automatically into any MCP server that exposes at least one CORTEX_AGENT_RUN or CODING_AGENT tool: ASYNC_AGENT_RUN_STATUS to poll a run, ASYNC_AGENT_RUN_CANCEL to stop it, and AGENT_RUN_RESULT to read the reply of any agent run by its handle. A new content_cel_filter parameter on the agent tools and on AGENT_RUN_RESULT lets a client ask for an outline of the answer first and then fetch only the blocks it needs, such as a single table.

For data teams that connect Claude, ChatGPT, Cursor or another MCP client to governed Snowflake data, the change addresses a practical failure point. Many MCP clients cap how long a single tool call may run, and an agent question that has to plan, generate SQL, run several queries and summarize the results can take longer than that cap. Snowflake's cookbook previously solved this with a custom pair of stored procedures for submit and fetch; the new tools move that pattern into the managed server.

··········

WHAT SNOWFLAKE ADDED TO THE MANAGED MCP SERVER.

The Snowflake-managed MCP server is a Snowflake object, created with CREATE MCP SERVER, that publishes Snowflake capabilities as Model Context Protocol tools. The documentation lists six tool types: CORTEX_AGENT_RUN for a Cortex Agent, CODING_AGENT for the Coding Agent, CORTEX_SEARCH_SERVICE_QUERY for Cortex Search, CORTEX_ANALYST_MESSAGE for Cortex Analyst over a semantic view, SYSTEM_EXECUTE_SQL for SQL execution, and GENERIC for user-defined functions and stored procedures. The November release touches only the two agent tool types, because they are the ones that run multi-step work and can exceed a client's time limit.

........

Addition	What it does	Applies to
background argument	Returns a run handle immediately	CORTEX_AGENT_RUN, CODING_AGENT
ASYNC_AGENT_RUN_STATUS	Reads the status of one run	Added automatically
ASYNC_AGENT_RUN_CANCEL	Stops a run that is in progress	Added automatically
AGENT_RUN_RESULT	Returns the stored reply of a run	Added automatically
content_cel_filter	Selects which content blocks come back	Agent tools, AGENT_RUN_RESULT

........

The release note does not label the change as a preview. The underlying Cortex Agents documentation states that background runs are generally available on AWS and Azure, and the long-running agents recipe in Snowflake's Cortex AI cookbook lists Enterprise edition on AWS or Azure as its scope and advises teams on Google Cloud to skip that pattern. Snowflake does not publish separate pricing for the new tools.

··········

HOW A BACKGROUND CORTEX AGENT RUN WORKS OVER MCP.

When the client calls an agent tool with background set to true, the response is a handle with four fields: run_id, thread_id, status and next_step. The status is in_progress at that point. The run_id has the form of the thread ID followed by a hyphen and the user message ID, and the documentation's own example is 12345-7.

The client then calls ASYNC_AGENT_RUN_STATUS with that run_id. The tool returns one of five statuses: in_progress, input_required, completed, cancelled or failed, together with a next_step string that tells the client model what to do next. When the status is completed, next_step points to AGENT_RUN_RESULT, which returns the stored assistant message. The result carries the run_id, the thread_id and a message_id. To continue the same conversation, the client passes the thread_id and sets parent_message_id to that message_id on the next agent call.

The input_required status covers runs that are waiting for a permission decision. In that case the status and result tools return the pending permissions, the message ID and a readable text, and the client answers by calling the agent tool again with permission_decisions, the thread_id, the parent_message_id and background set to true. A run can be stopped at any time with ASYNC_AGENT_RUN_CANCEL; for a run that has already finished, the cancel tool returns its current status.

The Cortex Agents REST documentation gives the time limits behind this design. A synchronous agent request times out after 15 minutes by default, while a background run continues for up to 6 hours, even if the client disconnects. Background runs require threads, because the answer is stored in the thread and read back from there. On the REST side, a canceled run keeps its partial output in the thread and is billed for the work already done, and usage is reported per model as input and output tokens.

··········

READING ONLY THE PARTS OF THE ANSWER YOU NEED.

An agent reply from Cortex Agents can contain several content blocks of different types, including tables. Passing all of them back into a chat model wastes context and can push a client over its own response limits. The content_cel_filter parameter controls what comes back. The default value, compact, keeps a subset that Snowflake describes as likely to be relevant to most clients. The value full keeps every block. The value outline replaces the content with one short entry per block showing its index, type and size.

Any other string is treated as an expression in the Common Expression Language, where content is the list of blocks and response is the whole message. Snowflake's documentation gives two examples of a follow-up selection after an outline:

content.filter(c, c.type == 'table')
[content[3]]

The first expression returns only table blocks, and the second returns the fourth block of the list. If an expression fails to evaluate, the result contains the outline and the error message so the client can try again. AGENT_RUN_RESULT accepts the same filter, so it is also useful for synchronous runs: a client can request the outline, then read a single result table without receiving the full narrative answer.

··········

ACCESS CONTROL FOR AGENT TOOLS IN THE MCP SERVER.

The supplementary tools follow Snowflake access control. The documentation states that a user cannot use them to reach runs or threads that the user does not have access to, so knowing a run_id is not enough to read another user's results. Snowflake's long-running agents recipe also notes that its procedures run with caller's rights, so row access and masking policies on the underlying tables still apply to the requesting user.

........

Privilege	Object	Purpose
USAGE	MCP server	Connect and list tools
USAGE	Cortex Agent	Call the agent as a tool
SELECT	Semantic view	Call the Cortex Analyst tool
USAGE	Cortex Search Service	Call the search tool
USAGE	UDF or procedure	Call a GENERIC tool
MODIFY	MCP server	Update, drop, describe and use
OWNERSHIP	MCP server	Change the configuration

........

For an agent-based server, Snowflake's example also grants the SNOWFLAKE.CORTEX_AGENT_USER database role and USAGE on the warehouse, database and schema. If the active role lacks USAGE on an agent, tools/list simply omits that CORTEX_AGENT_RUN tool, which is a common reason an agent appears to be missing in a client. Snowflake advises granting the role only to the users who need it and never to PUBLIC. Teams that already modeled their metrics in a semantic view, including the recent level of detail metrics in Snowflake semantic views, get those definitions through the agent with the same grants.

··········

LIMITS OF THE SNOWFLAKE-MANAGED MCP SERVER.

The managed server supports MCP revision 2025-11-25 and only the tools capability of the protocol. Resources, prompts, roots, notifications, sampling and dynamic client registration are not supported. Each server can hold at most 50 tools across all types, and the documentation warns that higher counts can reduce tool-selection accuracy. Responses from GENERIC and SQL execution tools are truncated at 250 KB, and Snowflake enforces a maximum recursion depth of 10 invocations.

Tool call responses are delivered as a Server-Sent Events stream, so clients must send an Accept header that includes both application/json and text/event-stream. MCP server objects are not replicated in failover groups and have to be recreated on a secondary account, although OAuth security integrations do replicate. Hostnames must use hyphens instead of underscores. Snowflake names Claude.ai, Claude Desktop, ChatGPT and Cursor among compatible clients, with Okta and Microsoft Entra ID as external OAuth identity providers.

··········

WHAT ANALYTICS TEAMS SHOULD CHECK BEFORE SWITCHING.

Teams that built the submit-and-fetch procedures from the cookbook can now compare them with the built-in tools. The custom approach waits on the server for up to 60 seconds per fetch call, which reduces the number of model-driven polls; the built-in status tool returns the current state of the run, so the number of polling calls depends on how often the client checks. The recipe itself suggests that cutting agent latency through verified queries, a narrower semantic view, fewer tools or a right-sized warehouse may be cheaper than any long-running pattern.

Before relying on background runs in production, a BI or platform admin should confirm four points: that the account runs on AWS or Azure; that the agent uses threads, since background runs depend on them; that each analyst role has USAGE on the agent and the MCP server plus SELECT on the semantic views the agent queries; and that the client in use keeps calling the status tool until it sees completed. The same governance questions apply to other MCP-based analytics front ends, such as Tableau Data Apps built from Claude and ChatGPT and the OpenAI Data agent with Snowflake, BigQuery and Databricks connections.

Background runs extend the same governed-data approach seen in Snowflake's HTML reports from Cortex Code shared by role to the slower agent questions that previously failed on client time limits. The cookbook recipe notes that some clients stop after the first answer that says the run is still going, so the client should be instructed to keep polling until the run completes.

··········

SNOWFLAKE MCP BACKGROUND RUNS: WHAT IS DOCUMENTED AND WHAT IS NOT.

Snowflake's documentation confirms the background argument on CORTEX_AGENT_RUN and CODING_AGENT tools, the three supplementary tools added automatically, the five run statuses, the run_id format, the content_cel_filter values and the access-control guarantee that users cannot read runs they have no rights to. The Cortex Agents documentation confirms a 6-hour limit for background runs against 15 minutes for synchronous requests, with general availability on AWS and Azure.

The documentation does not state how long run results remain readable through AGENT_RUN_RESULT, does not publish a separate price for background runs beyond the token usage reported per model, and does not list support on Google Cloud. Behavior with a specific MCP client, including how it handles repeated polling, depends on that client and should be tested with a real agent question that runs longer than the client's time limit before the setup goes to analysts.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org