Designing a Snowflake MCP Server, Built for Your Data

AI agents can reason, but on their own they cannot safely reach your governed enterprise data, and wiring each one up by hand is brittle and hard to govern. Snowflake's managed MCP server solves the connection, but the more interesting question is what you let an agent actually do once it is connected. This session is for Snowflake customers and Solutions Engineers who want to move past read only question answering and design a governed tool surface, one where an agent can search, run queries, and take real actions, all inside Snowflake's security boundary.

The managed MCP server turns the Model Context Protocol into a native Snowflake object, and it exposes five kinds of tools that span a full spectrum: Cortex Analyst and Cortex Search for answers, SYSTEM_EXECUTE_SQL for running queries, a GENERIC tool that wraps your own stored procedure for taking actions, and CORTEX_AGENT_RUN for delegating to a whole agent. We assemble exactly the tools we want with a single CREATE MCP SERVER statement, so the tool surface, and the blast radius, is a deliberate design choice. Every call runs as the connecting user's role, with OAuth, RBAC, masking, and audit applied automatically.

In this Hands-on Lab, we will design a tool surface and move from answers to actions:

• Build the read tools first, a semantic view for Cortex Analyst and a Cortex Search service, then assemble a scoped MCP server and connect a live AI client
• Add SYSTEM_EXECUTE_SQL so the agent can run its own queries, and see how read_only and your role cap what it can touch
• Wrap a stored procedure as a GENERIC tool and watch the agent take a real, audited action, reading customer reviews and then filing a support ticket, all on a scoped warehouse with least privilege
• Optionally expose an entire Cortex Agent as a single tool, or serve Cortex Code over MCP, to delegate multi step work

Attendees will leave knowing how to design and govern a Snowflake MCP tool surface across the full range, from read only answers, to running SQL, to taking a governed write back action, with no data leaving Snowflake's boundary. Because some of these tools can act, we will cover the governance a read only lab never has to: least privilege on the single procedure a write tool can call, keeping a human in the loop on writes, and treating each tool's description as the agent's whole API surface. The tools in the server spec and the connecting role together decide exactly what an agent is allowed to do, so it can move from telling you a problem exists to resolving it, and attendees can apply the same pattern to their own semantic views, Cortex Search services, and procedures.