Como saber quem realmente usa o seu servidor MCP do Snowflake
Aprofundamento CEVIU
Aprofundamento
O problema é simples de descrever: o Snowflake não tem coluna que diga por qual servidor MCP uma query chegou. O texto do Snowflake mostra que a saída está no login. Clientes MCP como Claude Desktop, Claude Code e Cursor entram por uma security integration OAuth, e o Snowsight usa SSO ou senha. Cada query aponta para o login da sessão por QUERY_HISTORY.AUTHN_EVENT_ID, que casa com LOGIN_HISTORY.EVENT_ID, onde fica AUTHORIZING_INTEGRATION_NAME. Query do Snowsight vem com esse campo vazio. Na conta de teste do autor, a chave alternativa via SESSIONS.LOGIN_EVENT_ID bateu em 100% das linhas em 30 dias, mas o caminho direto economiza um join.
Um ponto de configuração que o título pede: o OAUTH_REDIRECT_URI da integração. Para Claude Desktop e claude.ai, vale a URL de callback do claude.ai. Claude Code escuta em localhost, então precisa de um callback http://localhost com OAUTH_ALLOW_NON_TLS_REDIRECT_URI = TRUE. O autor avisa que uma integração só com o URI de localhost não funciona no Claude Desktop. Convém também usar OAUTH_USE_SECONDARY_ROLES = NONE, para que ROLE_NAME mostre o que o usuário podia ver.
Há limites reais. A integração registra como o cliente entrou, não qual servidor ele chamou, então o mapeamento integração-servidor é convenção sua: uma integração por servidor dá uso por servidor. Logins por PAT ou par de chaves não têm nome de integração e ficam fora. AGENT_TYPE ajuda a achar esse tráfego, mas o autor só o viu com OAuth. QUERY_TAG identifica a chamada, não o servidor: 258 de 3.044 queries com tag, nos últimos 90 dias dele, estavam fora das integrações MCP. Também é preciso excluir a query LIST de skills que o Snowflake dispara antes das chamadas, que dobra a contagem, e contar chamadas por sessão, já que cada chamada abre uma sessão nova.
Por que isso importa
Para quem opera dados no Snowflake, isso transforma a pergunta "alguém usa esse MCP?" em um modelo de consumo que dá para pôr em dashboard. O dado que o autor achou mais útil foi a fatia: em sua conta, o MCP respondia por 6 a 14% das queries de quem o usa. Na leitura do CEVIU, isso serve de base para governança e custo, mas só se o nome da integração for pensado como dimensão de relatório desde o início e se o client ID ficar restrito a clientes MCP.
Perguntas frequentes
Como diferenciar uma query do Snowsight de uma enviada via MCP no Snowflake?
Junte QUERY_HISTORY a LOGIN_HISTORY por AUTHN_EVENT_ID e EVENT_ID. A coluna AUTHORIZING_INTEGRATION_NAME vem vazia no Snowsight e traz o nome da integração OAuth no caso do MCP.
Preciso de uma integração OAuth por servidor MCP?
Se quiser medir uso por servidor, sim. A integração só registra como o cliente entrou, não qual servidor ele chamou. Com uma integração compartilhada, você vê o uso do grupo e ainda separa ferramenta SQL de ferramenta de agente com AGENT_TYPE.
Logins por PAT ou par de chaves aparecem nessa medição?
Não. Nesses logins AUTHORIZING_INTEGRATION_NAME fica vazio. Dá para procurar o tráfego por AGENT_TYPE e, no caso do PAT, pelo nome do token em CREDENTIALS, mas isso depende de convenção de nomes.
Por que contar sessões e não logins para medir chamadas?
Cada chamada de ferramenta MCP abre uma sessão nova, então sessões distintas em QUERY_HISTORY medem a frequência. LOGIN_HISTORY inclui logins sem query: o autor viu 6.300 em 90 dias sem nenhuma consulta, contra 230 que executaram queries.
Fontes
- medium.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 12 de novembro de 2026
- Editoria
- CEVIU Dados
