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

### 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_

No repository files, tests, or entry points are identified. Start by reproducing the streamable-http OAuth connection in Claude Desktop and claude.ai, then compare LOGIN_HISTORY and QUERY_HISTORY_BY_USER for the failing user against the working Snowflake user. Done means a tool invocation succeeds and produces a corresponding Snowflake query.

Escrito por el modelo de indexación a partir del texto del issue.