OAuth Streamable HTTP MCP tools never injected into Claude context after tools/list - NetSuite

[majormatt80]

LibreChat Version: v0.8.6
Deployment: Docker Compose on GCP VM (Ubuntu)
MongoDB: 8.0.20
Transport: streamable-http
Auth: OAuth 2.0 Authorization Code Grant + PKCE
MCP Server: NetSuite AI Connector Service (native Oracle NetSuite MCP)
Model Tested: claude-sonnet-4-6 (Anthropic endpoint)

[Bug]: OAuth Streamable HTTP MCP — tools/list never called after successful OAuth, tools not injected into Claude context (NetSuite AI Connector)
Environment
yaml
LibreChat Version: v0.8.6
Deployment: Docker Compose on GCP VM (Ubuntu)
MongoDB: 8.0.20
Transport: streamable-http
Auth: OAuth 2.0 Authorization Code Grant + PKCE
MCP Server: NetSuite AI Connector Service (native Oracle NetSuite MCP)
Model Tested: claude-sonnet-4-6 (Anthropic endpoint)
Describe the Bug
After successful OAuth 2.0 + PKCE flow, LibreChat establishes a connection to the NetSuite MCP server but never calls tools/list. Tool definitions are never fetched and never injected into Claude's context. Claude sees only the server name and the serverInstructions value — not the actual callable tools.

As a result:

Claude hallucinates tool responses using memory instead of executing real tool calls
<tool_call> and <tool_response> appear as literal text in the chat (simulated, not executed)
Agent Builder shows "netsuite — A collection of tools from netsuite" with zero individual tools listed
Asking Claude for exact tool names returns "server instructions only contain 'false'" — no tools enumerated
What Should Happen
After OAuth completes:

initialize handshake sent with Bearer token ✅
Connection established ✅
tools/list called ← This never happens ❌
Tool definitions injected into Claude's context ← Never happens ❌

info: [MCP][netsuite] OAuth Required: true
info: [MCP][netsuite] Tools: undefined ← Never populated
info: [MCP] Initialized with 1 configured server and 0 tools.
info: [MCP OAuth] OAuth flow completed, tokens received ✅
info: [MCP][netsuite] Loaded OAuth tokens ✅
info: [MCP][netsuite] Connection successfully established ✅
← NO tools/list log line ever appears after this

The same NetSuite MCP server works perfectly with Claude.ai (Anthropic's native client), which returns all 14 tools with ns_ prefix and executes real queries returning verified NetSuite data.

mcpServers:
netsuite:
type: streamable-http
url: https://[accountid].suitetalk.api.netsuite.com/services/mcp/v1/all
requiresOAuth: true
startup: true
timeout: 30000
serverInstructions: false
oauth:
authorization_url: "https://[accountid].app.netsuite.com/app/login/oauth2/authorize.nl"
token_url: "https://[accountid].suitetalk.api.netsuite.com/services/rest/auth/oauth2/v1/token"
client_id: "[redacted]"
scope: "mcp"
redirect_uri: "https://[domain]/api/mcp/netsuite/oauth/callback"
pkce: true

This appears to be the same class of bug documented here:
github.com
More details about github.com

After a successful OAuth 2.1 + PKCE S256 authorization flow against a remote http-transport MCP server, the client silently fails to register the post-auth tool catalog. The cause is client-side, in the code path that should re-handshake an http-transport MCP server after a successful OAuth dance and call tools/list on it.
github.com
More details about github.com

Steps to Reproduce
Configure a streamable-http MCP server with OAuth in librechat.yaml
Start LibreChat and complete the OAuth consent flow
Confirm connection established in logs
Open Agent Builder → Tools → see server listed but 0 individual tools
Ask Claude the exact tool names → Claude says it cannot see them
Ask Claude to call a tool by exact name → Claude hallucinates a response using memory instead of executing

Expected Actual
After OAuth tools/list called, tools injected No tools/list, 0 tools
Agent Builder 14 tools listed 0 tools listed
Tool calls Real NetSuite data returned Claude hallucination
Chat area Tools executable Tools simulated as text

[danny-avila]

If you could provide the information required from the issue template, it would help troubleshoot:

In LibreChat, open Settings → About and click Copy diagnostics, then paste the result here.
This captures the exact version, commit, branch, and build date so maintainers can pinpoint the build you're running.

https://github.com/danny-avila/LibreChat/blob/main/.github/ISSUE_TEMPLATE/BUG-REPORT.yml

also more logs surrounding the actual chat request as indicated by the issue template would help, too

[majormatt80]

LibreChat version: v0.8.6
Commit: 566e20b
Branch: v0.8.6
Build date: 2026-06-01 03:12:55 UTC
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36

Root Cause Identified with Debug Logs
After enabling DEBUG_CONSOLE=true and capturing full debug logs, the exact failure point has been identified.

What the Logs Show
tools/list IS being called and returns 17 tools successfully:
2026-06-16T16:27:20.462Z debug: [MCP][User: [USER-ID]][netsuite] Transport sending: method=tools/list id=2
2026-06-16T16:27:20.736Z debug: [MCP][User: [USER-ID]][netsuite] Transport received: method=response id=2
2026-06-16T16:27:20.742Z debug: [MCP Cache] Updated 17 tools for server netsuite (user: [USER-ID])

But when initializeClient builds the LLM request, it loads 0 tools:
2026-06-16T16:27:58.809Z debug: [initializeClient] Storing tool context for
anthropic__claude-sonnet-4-6: 0 tools, registry size: 0

Confirmed in the LLM call completion — Claude received zero tool schemas:
2026-06-16T16:27:58.945Z debug: [agents:graph] Invoking LLM
{
messageCount: 1,
provider: "anthropic",
...
}

2026-06-16T16:28:08.990Z debug: [agents:graph] LLM call complete (10.05s)
{
input_tokens: 132,
output_tokens: 576,
total_tokens: 708,
toolSchemaTokens: 0, ← Claude received ZERO tool schemas
messageCount: 1,
...
}

OAuth 2.0 + PKCE flow completes | ✅
Access token and refresh token stored in MongoDB | ✅
Connection established to NetSuite MCP server | ✅
tools/list called after OAuth reconnect | ✅
17 tools returned by NetSuite and written to MCP Cache | ✅
initializeClient reads from MCP Cache into LLM tool context | ❌ 0 tools loaded
Claude receives tool schemas in API request | ❌ toolSchemaTokens: 0

Possibly Related Warning
This warning appears every OAuth callback and may be related to the cache not being associated with the correct session context:
warn: [MCP OAuth] oauthHeaders absent from flow state —
config-source server oauth_headers will be empty

Additional Context
This only affects OAuth-protected streamable-http MCP servers configured via librechat.yaml
Non-OAuth MCP servers work correctly (tools ARE passed to LLM context)
The same NetSuite MCP server works perfectly in Claude.ai (native Anthropic client) which correctly calls tools/list and injects all 17 tool schemas into Claude's context
The MCP server is NetSuite AI Connector Service (Oracle) using OAuth 2.0 Authorization Code Grant + PKCE, scope: mcp
LibreChat version: v0.8.6

librechat.yaml config some values redacted for security purposes.

mcpServers:
netsuite:
type: streamable-http
url: https://[ACCOUNT-ID].suitetalk.api.netsuite.com/services/mcp/v1/all
requiresOAuth: true
startup: true
timeout: 30000
serverInstructions: false
oauth:
authorization_url: "https://[ACCOUNT-ID].app.netsuite.com/app/login/oauth2/authorize.nl"
token_url: "https://[ACCOUNT-ID].suitetalk.api.netsuite.com/services/rest/auth/oauth2/v1/token"
client_id: "[REDACTED]"
scope: "mcp"
redirect_uri: "https://[YOUR-DOMAIN]/api/mcp/netsuite/oauth/callback"
pkce: true

Let me know if you need anything else.

[danny-avila]

Your build is v0.8.6 / 566e20b (~June 1), which predates a round of MCP fixes that landed mid-June. Your logs show the OAuth flow and tools/list actually working, the tools get discovered and cached (Updated 17 tools), they just never get threaded into the LLM request (Storing tool context … 0 tools, toolSchemaTokens: 0).

The mechanism that carries discovered MCP tools into the agent context didn't exist yet on your build; it was added and hardened in #13626, #13669, #13673, and #13672.

The oauthHeaders absent from flow state warning was part of that same OAuth-callback rework.

Could you pull latest main (or dev), rebuild, and retest? Good chance it's already resolved. If it still reproduces, let me know, we can chase it down with any OAuth streamable-http MCP.

[majormatt80]

Great! I will wait until 0.87 is released as I see it is in RC1 right now. Then I will test again.

[majormatt80]

Still broken in v0.8.7

Upgraded from v0.8.6 to v0.8.7 and the issue persists unchanged. The fixes in #13669, #13672, and #13673 did not resolve this case.

Root cause now clearly identified from debug logs:

The timing sequence is:

sql
19:42:05 [getMCPTools] No tools found for server netsuite
← chat request initializes with 0 tools

19:42:12 [MCP Cache] Updated 17 tools for server netsuite ✅
← tools arrive AFTER initializeClient already ran

19:43:36 [initializeClient] Storing tool context: 0 tools, registry size: 0 ❌
← never reads from cache populated 90 seconds earlier

toolSchemaTokens: 0 ❌
← Claude receives zero tool schemas every time
The specific failure: initializeClient is called before the OAuth reconnect + tools/list cycle completes. When getMCPTools is called at chat initialization time, the cache is empty. By the time tools/list response arrives and populates the cache (∼90 seconds later in this session), initializeClient has already built the LLM context with 0 tools and does not re-check the cache.

Expected behavior: initializeClient should either:

Wait for the MCP cache to be populated before building tool context, OR
Re-read from the MCP cache immediately before invoking the LLM (after OAuth reconnect completes)
Environment:

LibreChat: v0.8.7
MCP server: NetSuite AI Connector (streamable-http + OAuth 2.0 + PKCE)
Model: claude-sonnet-4-6 (Anthropic endpoint)

[CedricConday]

From the MCP-protocol side: after the OAuth handshake, the client must treat it as a fresh authenticated session and re-run discovery on it — initialize → notifications/initialized → tools/list over the now-authenticated transport. The classic break is that the OAuth callback completes on a different session than the one the agent later uses, so tools/list is either never issued or issued on an unauthenticated session that returns empty — exactly your symptom.

Two things to capture to confirm:

1. On the MCP server, does an initialize + tools/list arrive after the token is issued, on the same session id?
2. Is the streamable-http session id preserved across the OAuth redirect, or is a new one minted?

If tools/list never reaches the server post-auth, it's client-side session continuity, not the server. That NetSuite connector is fine if tools/list works with a static token — which isolates it to the OAuth-reconnect path.

[majormatt80]

July 9 2026 Update — Three Additional Findings

Finding 1: tools/list never called post-reconnect (consistent)

Across three OAuth cycles, tools/list was never called after
Connection successfully established:

20:40:10 Connection successfully established ✅
20:40:10 Successfully reconnected ✅
← NO tools/list ❌
← NO MCP Cache update ❌

20:41:27 Connection successfully established ✅
20:41:27 Successfully reconnected ✅
← NO tools/list ❌

20:42:51 Connection successfully established ✅
20:42:51 Successfully reconnected ✅
← NO tools/list ❌

Finding 2: Token revocation loop is destroying sessions

NetSuite returns HTTP 405 on the revocation endpoint
(token revocation is not supported). LibreChat's
updateUserPluginsController responds by disconnecting
the authenticated session, triggering a new OAuth cycle
before tools/list can ever be called:

20:40:01 Revoking tokens → HTTP 405 ❌
20:40:02 updateUserPluginsController → disconnect → new OAuth
20:41:17 Revoking tokens → HTTP 405 ❌
20:41:17 updateUserPluginsController → disconnect → new OAuth
20:42:41 Revoking tokens → HTTP 405 ❌
20:42:41 updateUserPluginsController → disconnect → new OAuth

This revocation loop may be the primary cause of tools/list
never being called — the session is destroyed before
discovery completes.

Finding 3: oauthHeaders absent on every OAuth callback

warn: [MCP OAuth] oauthHeaders absent from flow state —
config-source server oauth_headers will be empty

This appears on every OAuth callback. The missing headers
may be causing the post-auth transport to be treated as
unauthenticated, preventing tools/list from being issued.

Summary of two distinct failure modes observed:

Mode A (June 26): tools/list called and cached 17 tools ✅
but initializeClient reads 0 tools from different session ❌

Mode B (July 9): tools/list never called at all ❌
caused by HTTP 405 revocation loop destroying sessions

NetSuite does not support the OAuth revocation endpoint
(returns HTTP 405). Can LibreChat handle a 405 on revocation
gracefully without destroying the authenticated session?

[CedricConday]

Your Finding 2 is the primary cause, and the other two follow from it. A revocation endpoint is optional under RFC 7009, and a client is not entitled to treat a failed revocation as a reason to tear down its own authenticated session — a 405 means the endpoint does not exist, which is a no-op, not a failure. LibreChat clearing its stored tokens locally is correct; disconnecting the live MCP session on a non-2xx revocation response is not.

That also explains Finding 1 without needing a second bug: the session is destroyed between "successfully reconnected" and the point where discovery would run, so tools/list never gets issued. The cheap confirmation is to stub the revocation call to a local no-op and re-run one OAuth cycle. If tools/list fires and the tools populate, Finding 2 is the whole of it and Finding 3 is cosmetic; if it still does not fire, then the missing oauthHeaders is a genuine second defect on the post-auth transport and worth its own issue.

Worth filing as a bug in its own right regardless of the NetSuite specifics: any MCP server that does not implement revocation will hit this same loop.

[majormatt80]

Any other thoughts on this one? @danny-avila

[majormatt80]

After placing the Netsuite MCP configuration in the librechat.yaml file the authentication is now working! @danny-avila Thank you so much for your continued work and efforts on LibreChat. Such as wonderful product.