Servidor MCP de Snowflake: herramientas, configuración y control de costes

Qué es el servidor MCP de Snowflake

ElEl servidor MCP de Snowflake es un endpoint MCP gestionado por Snowflake que se ejecuta dentro de una cuenta de Snowflake. Model Context Protocol es el estándar abierto que permite a un agente de IA descubrir y llamar a herramientas en un sistema externo, y la implementación de Snowflake convierte las funciones de Cortex y el SQL sin procesar en herramientas ejecutables.

La diferencia estructural respecto a un servidor MCP SaaS alojado: tú defines la superficie de herramientas. El servidor se crea con CREATE MCP SERVER ... FROM SPECIFICATION, donde la especificación es un archivo YAML que enumera cada herramienta, su tipo y su configuración. No aparece nada en tools/list que no hayas escrito tú mismo.

Se admiten cinco tipos de herramientas:

Una especificación mínima es sencilla: una entrada SYSTEM_EXECUTE_SQL con read_only: true, un tiempo de espera y el nombre de un almacén, y ya tienes un servidor MCP de almacén de datosfuncional. Los tipos de herramientas de Cortex requieren requisitos previos, ya sea un servicio de Cortex Search existente o una vista semántica.

Tres límites que conviene recordar: un máximo de 50 herramientas por servidor, respuestas truncadas a 250 KB, y los objetos de servidor MCP no se replican en grupos de conmutación por error.

Qué hacen realmente los agentes con él

Los usos que realmente importan encadenan herramientas en lugar de lanzar una única consulta:

• Análisis ad-hoc. Un analista pregunta en lenguaje natural; el agente llama a CORTEX_ANALYST_MESSAGE contra una vista semántica de ingresos, obtiene SQL y resultados, y explica la cifra. Este es el clásico agente de texto a SQL, salvo que la semántica reside en Snowflake en lugar de en un prompt.
• Recuperación híbrida. Un agente de soporte consulta un servicio de Cortex Search sobre la documentación del producto, luego ejecuta una herramienta SQL para conocer el estado de la cuenta del cliente y responde con ambos datos.
• Depuración de pipelines. Un agente comprueba el recuento y la actualización de filas con SQL, encuentra una partición obsoleta y lee los metadatos del trabajo ascendente desde otra tabla.
• Conciliación de métricas. Dos paneles no coinciden. El agente ejecuta ambas definiciones, compara los conjuntos de filas y señala dónde divergen.

La división entre lectura y escritura se percibe de forma distinta aquí. En un almacén de datos, las lecturas son la parte peligrosa. Una escritura errónea suele romper una tabla que puedes restaurar. Una lectura errónea puede devolver silenciosamente la información personal (PII) de todos los clientes y costar cientos de dólares en computación antes de que alguien se dé cuenta.

Por qué la conexión directa falla a escala de equipo

Que un analista apunte un cliente MCP a su propia cuenta está bien. Que lo hagan treinta es un problema distinto.

El coste de computación es ahora una decisión del agente. Snowflake factura la computación del almacén por segundos mientras este está en funcionamiento, con un cargo mínimo por cada reanudación. Un agente que escribe su propio SQL decide, sin supervisión, si escanear una partición o un petabyte, y una cláusula WHERE ausente en una tabla de hechos grande es un error de una línea con una factura de cuatro cifras. Los agentes también reintentan: una llamada que agota el tiempo de espera a los 600 segundos y se reintenta cinco veces supone cinco escaneos completos, sin que nada en el protocolo le indique que debe parar. Este es el único servidor donde las métricas de herramientas y los límites de tasa son un control presupuestario, no una cuestión de optimización operativa.

Amplitud de lectura. El almacén de datos es el único sistema donde toda la información confidencial ya está consolidada. Tu repositorio contiene secretos; tu sistema de tickets, nombres de clientes. Tu almacén tiene pedidos vinculados a usuarios y a pagos, todo en un esquema al que un rol con permisos amplios puede acceder. Un simple SELECT con demasiados privilegios es una exposición mayor que cualquier cosa que un agente pudiera hacer en Git o Jira, y no deja rastro del daño. Los datos simplemente desaparecen.

Las credenciales compartidas destruyen la trazabilidad. Si todos los agentes se autentican como un único usuario de servicio con un único rol, cada fila en el historial de consultas de Snowflake tendrá el mismo autor. No podrás responder a la pregunta de «qué agente, actuando en nombre de quién, leyó la tabla de pagos a las 2 de la mañana», y las políticas por usuario son imposibles porque solo existe un usuario.

Nadie es responsable de la especificación. Dos equipos escribirán dos versiones, una cuidadosa y otra con read_only: false y sin tiempo de espera, y nadie controlará a qué agentes de producción acceden.

Ese es un argumento a favor de un plano de control que actúe como intermediario, que es lo que un pasarela MCP.

Want per-user Snowflake access without a shared service account?

Register your Snowflake MCP server on TrueFoundry and let each analyst authorize their own account over OAuth.

Get started free

Conexión del servidor MCP de Snowflake a través de TrueFoundry

Snowflake es no es una entrada de catálogo de un solo clic. El punto de conexión reside dentro de tu cuenta y su URL es específica de la misma, por lo que primero debes realizar la configuración en el lado de Snowflake y luego registrar la URL resultante a través de Conectar cualquier servidor MCP remoto.

Necesitas una cuenta de Snowflake en un plan de pago, ya que la ejecución de SQL está bloqueada en las versiones de prueba, además de permisos de ACCOUNTADMIN o CREATE INTEGRATION global, un almacén reanudable, la URL de tu cuenta escrita con guiones en lugar de guiones bajos, y un grupo de servidores MCP.

Paso 1: crear el objeto de servidor MCP. En una hoja de trabajo SQL de Snowsight (Proyectos > Hojas de trabajo, no en la pantalla de ingesta), ejecuta CREATE OR REPLACE MCP SERVER con la especificación de tu herramienta. La base de datos, el esquema y el nombre del servidor formarán parte de la URL del conector, así que elige un esquema grabable que no sea del sistema y evita el uso de $ en los nombres.

Paso 2: crear la integración de seguridad OAuth. Solo un ACCOUNTADMIN puede hacerlo. Utiliza TYPE = OAUTH, OAUTH_CLIENT = CUSTOM, OAUTH_CLIENT_TYPE = 'CONFIDENTIAL' para que el secreto permanezca en el lado del servidor, OAUTH_ISSUE_REFRESH_TOKENS = TRUE, una validez del token de actualización en segundos y OAUTH_ENFORCE_PKCE = TRUE. El URI de redirección es la devolución de llamada que se muestra en el Añadir servidor MCP formulario de TrueFoundry:

https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback

Un error común: no no es añada una BLOCKED_ROLES_LIST que contenga ACCOUNTADMIN o SECURITYADMIN. OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST ya los bloquea por defecto, por lo que incluirlos en la lista provocará un error. Recupere las credenciales con SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<INTEGRATION_NAME>'), en mayúsculas.

Paso 3: cree un rol que no sea de administrador y conceda acceso. Los roles de administrador están bloqueados para OAuth, por lo que el usuario debe aterrizar en un rol predeterminado sin privilegios. Conceda USAGE sobre el almacén, la base de datos, el esquema y el servidor MCP, y luego conceda los privilegios por herramienta por separado, como USAGE ON CORTEX SEARCH SERVICE o SELECT ON SEMANTIC VIEW. El acceso al servidor no no es concede acceso a sus herramientas. Establezca DEFAULT_ROLE y DEFAULT_WAREHOUSE en el usuario; la sesión de OAuth no se iniciará sin ellos.

Paso 4: permita la salida (egress) de la pasarela. Si las políticas de red están habilitadas, añada a la lista de permitidos las IP de salida de TrueFoundry. La pasarela se conecta de servidor a servidor desde la infraestructura de TrueFoundry, no desde el navegador del usuario, por lo que una sesión de navegador funcional no demuestra nada. En cuentas con PrivateLink, registre la pública URL de la cuenta y mantenga el punto de conexión del token público.

Paso 5: regístrese en TrueFoundry. En su grupo de servidores MCP, haga clic en Añadir servidor MCPy eligeConectar cualquier servidor MCP remoto.

Introduzca la URL del servidor MCP, que sigue este formato:

https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name>

SeleccionaOAuth2 con el tipo de concesión Código de autorización, luego rellene la URL de autorización https://<account_url>/oauth/authorize, la URL del token https://<account_url>/oauth/token-request, su ID de cliente y su secreto, Métodos de desafío de código admitidos S256, Fuente JWT Token de acceso y Ámbitos refresh_token. Establezca el control de acceso y, a continuación, Guardar. Almacene el ID de cliente y el secreto en el almacén de secretos de TrueFoundry y haga referencia al FQN en lugar de incluirlos directamente.

Sobre los ámbitos: mantenga refresh_token, ya que sin él las sesiones caducan aproximadamente cada diez minutos. Elimine la otra opción, session:role:<role>: el servidor la ignora, ya que resuelve el rol a partir de DEFAULT_ROLE, y añade un modo de fallo por distinción entre mayúsculas y minúsculas.

Cómo funciona realmente la autenticación

TrueFoundry mantiene autenticación de entrada la autenticación, cómo un cliente se identifica ante la pasarela, separada de autenticación de salida, cómo la pasarela se identifica ante Snowflake. Ambas capas son independientes.

Entradaadmite cuatro métodos:

Los tokens de cuenta virtual otorgan a cada solicitud el mismo acceso, por lo que no se pueden utilizar aquí. Para un almacén, donde todo el argumento de seguridad se basa en que cada persona hereda su propio rol, utilice un PAT o un token de IdP entrante.

Salida es Snowflake OAuth para la integración que ha creado. Para autorizar, abra la sección Herramientas del servidor o Añadir servidores de herramientas/MCP en el área de pruebas (Playground) y haga clic en Conectar ahora. Se le redirigirá a Snowflake para dar su consentimiento y TrueFoundry nunca verá sus credenciales.

Esta es la parte que protege sus datos. Cada usuario opera bajo sus propios permisos RBAC de Snowflake, resueltos a través de su DEFAULT_ROLE. La pasarela no decide qué filas puede ver; lo hace Snowflake. Todo lo que ya ha creado allí se aplica sin cambios: concesiones de roles en bases de datos, esquemas y tablas, además de políticas de acceso a filas y enmascaramiento dinámico de datos si los utiliza, los cuales requieren Snowflake Enterprise Edition o superior [VERIFICAR]. Un agente que actúa en nombre de un analista junior ve exactamente lo mismo que ve dicho analista.

Deje clara la división del trabajo: la pasarela determina qué herramientas existen, Snowflake determina qué filas se devuelven. Deshabilitar una herramienta no puede ocultar una tabla que un rol ya tenía permiso para leer, y restringir un rol no puede evitar que un agente llame a una herramienta de escritura que dejó habilitada. Consulte autenticación MCP para obtener más información sobre las dos capas.

Si cada cliente tiene su propia cuenta de Snowflake, un ID de cliente no puede abarcarlas todas, por lo que debe registrar una entrada independiente por cuenta.

Delimitar las herramientas antes de publicar

Una vez conectado, el HerramientasLa pestaña enumera todo lo que expone el servidor.

Interruptores por herramienta. Desactive una herramienta y se omitirá por completo de tools/list. Los clientes nunca la verán y no podrá ser invocada; esto no es un filtrado a nivel de prompt. El patrón habitual en el almacén de datos es dejar activos Cortex Analyst y Cortex Search mientras se deshabilita SYSTEM_EXECUTE_SQL sin procesar. Los analistas mantienen las consultas en lenguaje natural a través de una vista semántica que usted ha seleccionado, y el agente pierde la capacidad de redactar SQL arbitrario contra tablas arbitrarias. Eso es más barato y más seguro.

Habilitar nuevas herramientas por defecto. Si se dejan activadas, las herramientas añadidas a la especificación de Snowflake llegan a los agentes automáticamente. Si se desactivan, solo son accesibles las herramientas que usted habilitó explícitamente. Dado que la especificación la edita quien tiene privilegios en Snowflake y no quien posee la pasarela, la respuesta correcta es desactivarlas: así, un cambio en la especificación no puede ampliar silenciosamente lo que pueden hacer los agentes en producción. Acción masiva convierte cada fila en una casilla de verificación para que pueda modificar varias a la vez.

Haga clic en el lápiz de cualquier herramienta para anular cómo se presenta al modelo:

ElDescripción anular, hasta 20.000 caracteres, es especialmente valioso aquí. Las descripciones de las herramientas de Snowflake son lo que usted haya escrito en la especificación, y una descripción vaga hace que un modelo recurra a SYSTEM_EXECUTE_SQL cuando una herramienta de análisis seleccionada habría respondido a la pregunta. Anotaciones de herramientas MCPmarca una herramientaSolo lecturaoDestructiva, establecer readOnlyHint o destructiveHint, y alimentar las políticas de aprobación a continuación.

Quién puede hacer qué: roles de colaborador

El control de acceso se aplica a usuarios, equipos o cuentas virtuales en dos dimensiones: a qué servidores puede acceder una identidad y qué herramientas puede invocar.

El equipo de plataforma tiene el rol de Gestor, los equipos de análisis tienen el de Usuario, y un responsable de gobernanza tiene el de Aprobador. Es el mismo Control de acceso MCP modelo utilizado en todos los servidores del registro.

Ready to put a boundary around your warehouse?

Register Snowflake, disable raw SQL execution, and hand your analysts a curated text-to-SQL agent in one sitting.

Start free on TrueFoundry

u

Aprobación humana para herramientas destructivas

Deshabilitar herramientas es un método drástico. A veces, desea que un agente escriba en una tabla o ejecute una consulta sin límites, pero no sin supervisión. Cuando se llama a una herramienta restringida, la llamada se retiene, se crea una solicitud de aprobación y se notifica a los aprobadores. Una vez que una persona aprueba, las llamadas se realizan correctamente durante un periodo configurable. Cree una política en AI Gateway > Policies > MCP Tool Approval, marcada como Beta en la consola:

Cada política nombra los servidores que restringe y elige unámbito de aprobación:

Para Snowflake, lo habitual es nombrar la herramienta de ejecución SQL: mantenga activas las herramientas de Cortex seleccionadas y retenga cada llamada SQL sin procesar para que la revise una persona. Cuando los ámbitos se solapan, gana el más específico: el nombre gana a la destrucción, y esta gana a todo lo demás. Validezpuede serUna vez o basada en tiempo en minutos, y cuando las políticas entran en conflicto, gana la más restrictiva, por lo que "Una vez" gana a una ventana de 10 minutos, que a su vez gana a una de 30 minutos.

Los aprobadores reciben notificaciones por correo electrónico, Slack, PagerDuty o MS Teams, y cada solicitud muestra la herramienta, la política, el solicitante y el argumentos reales de la herramienta. En un almacén, esa última parte es la funcionalidad clave: un aprobador lee la cadena SQL literal antes de que se ejecute, por lo que un cross-join sin límites es detectado por una persona en lugar de aparecer en la factura del mes siguiente. Mientras está pendiente, quien realiza la llamada recibe un resultado JSON-RPC con _meta.approval_status: "pending" en lugar de un error, de modo que un agente bien configurado espera en lugar de bloquearse.

Los permisos se asignan por solicitante, por lo que aprobar a un analista no implica aprobar a todo el equipo.

Pruebas en el entorno de herramientas

Antes de asignar un agente, ejecute las herramientas manualmente. Haga clic en Probar junto a una herramienta, rellene los parámetros y Ejecutar herramienta para leer el JSON sin procesar. Probar está desactivado para las herramientas que ha apagado.

Aquí es donde los errores de configuración salen baratos. Una herramienta que da error casi siempre se debe a un permiso faltante, ya que USAGE ON MCP SERVER permite la detección pero no la ejecución. Una herramienta que se queda bloqueada suele significar que no hay un almacén predeterminado o que este no puede reanudarse.

Uso desde tu IDE

Abre la pestañaCómo usar pestaña para obtener la URL de su Gateway específica del inquilino y fragmentos de código listos para copiar y pegar.

Cubre Claude Code, VS Code, Claude Desktop, Cursor, Windsurf, Codex y los SDK de MCP para Python y TypeScript. Utilice la URL de esta pestaña en lugar de crearla usted mismo; un endpoint construido manualmente es la causa más común de que un cliente se conecte pero no muestre ninguna herramienta.

Lo que obtiene una vez que está detrás de la pasarela

En un almacén, la capa operativa es la forma de saber cuánto le están costando sus agentes.

Métricas a nivel de herramienta. El panel de métricas de MCP desglosa las solicitudes por segundo, la latencia en P50/P75/P90/P99, la tasa de fallos por tipo de error y un recuento de solicitudes clasificadas por herramienta.

Considere esto como un panel de control de gastos, no de latencia. La latencia P99 en una herramienta SQL es un indicador de cuánta capacidad de cómputo está consumiendo una larga cola de consultas, y una tasa de fallos creciente junto con un aumento en el número de llamadas es la señal característica de un bucle de reintentos consumiendo créditos. Nada de esto sustituye a los controles propios de Snowflake: mantenga un monitor de recursos en el almacén que utilizan las herramientas y establezca un query_timeout estricto.

Observabilidad completa de las solicitudes. Cada llamada a una herramienta se rastrea con la identidad del emisor, el nombre de la herramienta, las entradas y la latencia, exportándose a través de OpenTelemetry a Grafana, Datadog o Prometheus. Dado que la autenticación saliente es OAuth por usuario, la identidad del emisor coincide con la del usuario en el historial de consultas de Snowflake, por lo que la pregunta de "¿quién ejecutó esto?" tiene una respuesta única.

Barreras de seguridad. Los mecanismos de protección previos y posteriores a la ejecución de la herramienta aplican políticas a las llamadas, lo que en este caso significa inspeccionar un conjunto de resultados en busca de patrones de PII antes de que llegue al modelo.

Baja sobrecarga.La pasarela añade aproximadamente3-4 msde latencia y gestionamás de 350 RPS en una sola vCPU. Frente a una consulta medida en segundos, eso es ruido.

Un registro único.Una vez registrados varios servidores, puede agrupar un subconjunto seleccionado de herramientas tras un único punto de acceso con unServidor MCP virtual, por lo que un agente de informes obtiene una herramienta de análisis de Snowflake y una herramienta de publicación en Slack.

Revocación de acceso

Los administradores de inquilinos pueden borrar todas las credenciales almacenadas en el servidor con una sola acción, desde el menú de tres puntos junto a Editar:

Revocar todos los tokens elimina todas las anulaciones de autenticación y los tokens OAuth almacenados para todos los usuarios y cuentas virtuales en ese servidor, entra en vigor en la siguiente solicitud y queda registrado en los registros de actividad. Es irreversible y solo los administradores de inquilinos pueden verlo.

El límite es importante: esto borra los tokens solo en la puerta de enlace, no la concesión en Snowflake. Durante un incidente real, deshabilite también la integración de seguridad y rote el secreto del cliente.

Cosas a tener en cuenta

Las cuentas de prueba no pueden ejecutar SQL. La herramienta de ejecución de SQL está bloqueada en las cuentas de prueba. Si su prueba de concepto se realiza en una cuenta de prueba y la herramienta aparece pero nunca se ejecuta, esa es la razón.

El acceso al servidor no es acceso a la herramienta. GRANT USAGE ON MCP SERVER permite que un rol se conecte y descubra herramientas. Ejecutarlas requiere las concesiones subyacentes: USAGE en el servicio Cortex Search, SELECT en la vista semántica y privilegios de tabla para SQL.

Vistas semánticas, no modelos semánticos. CORTEX_ANALYST_MESSAGE acepta un identificador de vista semántica. Apuntarlo a un modelo semántico no funcionará, y el error no es evidente.

Lecturas relacionadas

• Qué es una puerta de enlace MCP: arquitectura y casos de uso
• Explicación de la autenticación MCP
• Control de acceso MCP: protección de agentes de IA con una puerta de enlace MCP
• Explicación del servidor MCP virtual
• Buenas prácticas de seguridad para el servidor MCP

Conclusión

El servidor MCP de Snowflake es la herramienta más potente que puede poner en manos de un agente y la que presenta los modos de fallo más costosos. La mayoría de los servidores en un registro corren el riesgo de una escritura embarazosa. Este corre el riesgo de una factura elevada y una lectura amplia de datos que ya han sido combinados por conveniencia.

No empieza desde cero con el segundo riesgo. El RBAC de Snowflake, las políticas de acceso a filas y las políticas de enmascaramiento son el control principal, y el OAuth por usuario es lo que hace que un agente los herede en lugar de evitarlos con una cuenta de servicio compartida. El trabajo de la puerta de enlace es la otra mitad: decidir qué herramientas existen, retener las peligrosas para que las gestione un humano y proporcionarle un registro de llamadas y una vista de métricas para que el coste deje de ser una sorpresa.

Connect your Snowflake MCP server on TrueFoundry,

Free to start