Cortex Agent SDK features¶
This topic covers feature-specific SDK patterns that build on the quickstart, conversations, and direct API topics. Use these patterns when your application needs MCP tools, managed coding-agent controls, or detailed streaming-event handling.
Use MCP servers with direct agent runs¶
The direct Agent API client can attach Snowflake MCP SERVER objects to inline agent runs and saved agent object
specifications. Create and grant access to the MCP server first. For SQL examples and privileges, see
Snowflake-managed MCP server and
Connectors for Cortex Agents.
Pass MCP server references in the mcp_servers field of the agent request or saved agent specification. Use this
field with api.agent.* methods. Cortex Code uses a different mcpServers option, described in
Use in-process MCP tools with Cortex Code.
Attach an MCP server to an inline run:
Add the same MCP server to a saved agent object:
Attach an MCP server to an inline run:
Add the same MCP server to a saved agent object:
Use in-process MCP tools with Cortex Code¶
Use an in-process SDK MCP server when a Cortex Code session needs access to state or functions inside your
application process. The SDK registers the server with the local Cortex Code CLI and dispatches tool calls back to your
handlers. This pattern doesn’t create a Snowflake MCP SERVER object.
In-process MCP tools are available only through the Cortex Code interface. For direct Agent API runs, use Snowflake
MCP SERVER objects with the mcp_servers field instead.
For SDK-managed in-process servers, use setMcpServers() to replace the server map. toggleMcpServer() applies to
transport-backed servers that the CLI owns.
When you define tool input schemas, validate arguments inside the handler. Schema metadata helps describe the tool to the model, but your application remains responsible for rejecting invalid input.
Configure managed coding-agent features¶
The direct API exposes api.codingAgent in TypeScript and api.coding_agent in Python for Snowflake-managed coding
agent runs. This resource expands coding-agent options into the standard Agent API request shape and sends the request
through api.agent.
Use these options when you need to configure the coding-agent toolset directly:
permissionPolicyorpermission_policy: choose whether tool operations are always allowed or ask for approval.workspaceMountsorworkspace_mounts: mount a workspace that the coding agent can read and write.disabledSkillsordisabled_skills: disable built-in skills for a run.stageSkillsorstage_skills: load skills from a Snowflake stage.streamandbackground: choose the same response modes as other direct Agent API calls.
The SDK validates some coding-agent options before sending the request. For example, invalid workspace mount
configuration can raise a client-side CortexAgentError.
Handle detailed streaming events¶
Use AgentRunStream callbacks when your application wants to update different UI regions for text, thinking,
tool-use status, tables, charts, warnings, and final metadata. Use the raw async iterator when you want to handle
server-sent event payloads yourself or tally event types emitted by a run.
For a list of common event names, see Streaming events. For response view helpers, see Cortex Agent SDK reference.
Next steps¶
- Use the direct Cortex Agent API: Run inline agents and saved agent objects.
- Cortex Code with the Cortex Agent SDK: Embed a local Cortex Code session.
- Cortex Agent SDK reference: Review response objects, errors, retries, and request options.
Legal notices¶
Where your configuration of Cortex Code uses a model provided on the Model and Service Pass-Through Terms, your use of that model is further subject to the terms for that model on that page.
The data classification of inputs and outputs are as set forth in the following table.
| Input data classification | Output data classification | Designation |
|---|---|---|
| Usage Data | Customer Data | Covered AI Features [1] |
For additional information, refer to Snowflake AI and ML.