anthropics / anthropics/claude-ai-mcp

Snowflake MCP tool invocations silently fail across two server objects and two Claude surfaces, despite successful OAuth

Abierto
#577 4 comentarios 2 reacciones 0 asignados Ver en GitHub
auth bug server-developer-report
Lenguaje dominante
Sin datos de lenguaje
Estrellas
471
Forks
76
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

### MCP server URL

https://{accountidentifier}.snowflakecomputing.com/api/v2/databases/{mydbname}/schemas/{myschemaname}/mcp-servers/{mymcpservername}

### Where does the issue occur?

During a conversation (after initial auth)

### Transport used

streamable-http

### Client registration type

Static

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2027-07-07 17:34:00-600

### Browser and OS

Edge Version 150.0.4078.48 - Windows 11

### Describe the issue

MCP tool calls to Snowflake-hosted MCP servers fail with a generic "Error occurred during tool execution" on every invocation, while the connector shows as successfully connected and other (non-Snowflake) MCP connectors work normally in the same session.
Environment:

Claude Desktop and claude.ai (web) — same failure on both
Two separate Snowflake MCP server objects tested: production (CLAUDE_MCP_SERVER) and a freshly created minimal test server (CLAUDE_MCP_SERVER_TEST), same failure on both
Snowflake OAuth security integration: MCP_OAUTH_INTEGRATION (Standard/Custom OAuth)

Steps to reproduce:

Connect to a Snowflake-hosted MCP server (Cortex Analyst / SQL execution tools) via OAuth
Connector shows "Connected," tools are discoverable and listed correctly
Invoke any tool, including a trivial one (sql-execution-tool running SELECT CURRENT_ROLE())
Every call fails with a generic execution error, no further detail returned

What we've ruled out:

Snowflake grants/permissions (confirmed via SHOW GRANTS, and via a different user account successfully querying the same objects)
Warehouse access (USAGE/OPERATE grants confirmed present)
Semantic view ownership (recent ownership change didn't change behavior either direction)
OAuth token expiry (SHOW INTEGRATIONS shows 90-day refresh validity, well within window; LOGIN_HISTORY shows every OAuth login succeeding, timestamps matching test attempts exactly)
General MCP outage (Microsoft 365 connector works fine in the same session)
Desktop-app-specific bug (reproduced identically on claude.ai web)
Account-wide auth cache (reproduced even after full account logout/login and fresh connector re-authentication)

Key evidence: SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY shows every OAuth login attempt from Claude succeeding. INFORMATION_SCHEMA.QUERY_HISTORY_BY_USER shows zero corresponding query attempts — meaning calls never reach Snowflake's query layer at all, despite authenticating successfully.
Notable comparison: A different Snowflake user, connecting to the exact same production MCP server, is working normally right now.

### Issue details

```shell
Claude Desktop and claude.ai (web) — same failure on both
Two separate Snowflake MCP server objects tested: production (CLAUDE_MCP_SERVER) and a freshly created minimal test server (CLAUDE_MCP_SERVER_TEST), same failure on both
Snowflake OAuth security integration: MCP_OAUTH_INTEGRATION (Standard/Custom OAuth)
```

### Expected behavior

It has been generating a Snowflake SQL and then the secondary sql-execution tool executes.

### Logs from your server

```shell
I don't have any access to the logs other than the logins that we verified were successful.
```

### Additional context

_No response_

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.