Session Management & Tool Invocation with Gateway vs Direct MCP Client–Server

[arjavdongaonkar]

Context

1. I have a simple MCP server built using FastMCP (Node.js).

2. I have a Python client using the Python MCP SDK to fetch tools and call them.

3. I have IBM Context Forge up and running, with my MCP server registered under the Gateways/MCP Servers tab.

   • As expected, all tools exposed by the MCP server appear under Global Tools.

4. To route calls through the Gateway, I created a Virtual Server, where I selected a subset of tools.

Current Behaviour

• Direct client → MCP server (no Gateway):

  • A single session is initialised on the MCP server.
  • Regardless of how many tools are invoked, everything happens within that one session.
  • I do notice multiple TCP connections, but still tied to one session.

• Client → IBM Context Forge (Gateway) → MCP server:

  • Multiple sessions are established on the MCP server.
  • The number of sessions matches the number of tool invocations.
  • I also see increased TCP connections on the MCP server port.

Python Client:

async with streamablehttp_client(
        "http://localhost:4444/servers/{virtual-server-id}/mcp"
    ) as (read_stream, write_stream, _):
        async with ClientSession(read_stream, write_stream) as session:

            await session.initialize()

            tools_result = await session.list_tools()
            result = await session.call_tool("ping-pong-ping", {})

Node.js MCP server:

const server = new FastMCP({
  name: "PingServer",
  version: "1.0.0",
});

server.addTool({
  name: "ping",
  description: 'Responds with "pong"',
  execute: async () => "pong",
});

Logs:

[FastMCP info] HTTP Stream session established
[mcp-proxy] establishing new SSE stream for session ID 5cffdad3-1e10-42d0-a166-48bcba895ba5
[mcp-proxy] received delete request
[mcp-proxy] received delete request for session 5cffdad3-1e10-42d0-a166-48bcba895ba5

Question

• Is this expected behaviour with IBM Context Forge?

• What is the correct/ideal industry practice for MCP client–server communication in such a setup?

  • Should a single client workflow map to a single MCP session (even if multiple tools are invoked)?
  • Or is the current “one session per tool invocation” the intended model when going through the Gateway?

• How should this setup be configured when factoring in authentication and security best practices?

Looking for insights on:

• Whether my Virtual Server + Gateway setup is the correct and recommended configuration.
• Best practices for session management in MCP client–server communication with IBM Context Forge in the middle.

[crivetimihai]

TL;DR: You're Right, This is Expected

The behavior you're seeing is exactly what should happen when Context Forge is configured in stateless mode (which it is by default). Let me break down what's going on:

Session Behavior Analysis

Direct Client → MCP Server

┌─────────────┐    ┌─────────────────┐
│ Python      │────│ FastMCP Server  │
│ Client      │    │ (Node.js)       │
│ (1 session) │    │ (1 session)     │
└─────────────┘    └─────────────────┘

• Single persistent session throughout the workflow
• Multiple tool calls reuse the same MCP session
• Expected MCP protocol behavior

Client → Gateway → MCP Server

┌─────────────┐    ┌─────────────────┐    ┌─────────────────┐
│ Python      │────│ Context Forge   │────│ FastMCP Server  │
│ Client      │    │ (stateless)     │    │ (Node.js)       │
│ (1 session) │    │ (new per call)  │    │ (multi sessions)│
└─────────────┘    └─────────────────┘    └─────────────────┘

• Client maintains 1 session with the gateway
• Gateway creates new sessions per tool invocation to backing server
• Why: Gateway is configured in stateless mode by default

What's Actually Happening

Your Current Config (check your .env file):

# Streaming HTTP Configuration  
USE_STATEFUL_SESSIONS=false    # ← This is why you see multiple sessions
JSON_RESPONSE_ENABLED=true

The Code Behind It (mcpgateway/transports/streamablehttp_transport.py around line 415):

if settings.use_stateful_sessions:
    event_store = InMemoryEventStore()
    stateless = False
else:
    event_store = None
    stateless = True              # ← Gateway creates new session per tool call

The Fix

For your use case (multiple tool calls in a workflow), you probably want stateful sessions:

Change your configuration:

# Enable session persistence
USE_STATEFUL_SESSIONS=true
JSON_RESPONSE_ENABLED=true

Why this helps:

• Single session per client workflow (like direct connection)
• Better performance - less connection overhead
• Context preserved between tool calls
• Easier on your FastMCP server resources

When to Use Each Mode

Stateless Mode	Stateful Mode
✅ Load balancing	✅ Conversational workflows
✅ High availability	✅ State-dependent tools
✅ Simple tool calls	✅ Performance optimization
❌ Context loss	❌ Session affinity required

Security Stuff (You're Already Doing This Right)

Your current setup is actually pretty solid:

# Your client code looks good
async with streamablehttp_client(
    "http://localhost:4444/servers/{virtual-server-id}/mcp"
) as (read_stream, write_stream, _):
    async with ClientSession(read_stream, write_stream) as session:
        await session.initialize()        # Single auth per workflow
        tools_result = await session.list_tools()
        result = await session.call_tool("ping-pong-ping", {})

You've got:

• Virtual Server isolation (tool filtering per virtual server)
• Authentication handled at the gateway level
• Proper session management
• The MCP protocol stuff is working correctly

Recommended Configuration

For Your Workflow (Conversational/Multi-tool):

# Enable persistent sessions
USE_STATEFUL_SESSIONS=true
JSON_RESPONSE_ENABLED=true

# Optional: Session timeout tuning
SESSION_TTL=3600  # 1 hour session lifetime
MESSAGE_TTL=300   # 5 minute message retention

Production Considerations:

# Security
AUTH_REQUIRED=true
JWT_SECRET_KEY=your-strong-secret

# Performance  
DB_POOL_SIZE=200
CACHE_TYPE=redis  # For session persistence across restarts

# Monitoring
METRICS_ENABLED=true
LOG_LEVEL=INFO

Verification Steps

1. Update Configuration:

   # In your .env file
   USE_STATEFUL_SESSIONS=true

2. Restart Gateway:

   make dev  # or your restart command

3. Test Session Behavior:

   • Run your Python client code
   • Check FastMCP logs for session establishment
   • Should see single session for multiple tool calls

4. Monitor Logs:

   # Gateway logs
   [INFO] Streamable HTTP session established: <session-id>
   
   # FastMCP logs (should show fewer session creations)
   [FastMCP info] HTTP Stream session established

Bottom Line

What you're seeing makes perfect sense:

• Your setup (Virtual Server + Gateway) is exactly how you should do this
• The "multiple sessions" behavior is just because of the stateless default
• Flip USE_STATEFUL_SESSIONS=true and you'll get the session behavior you expect
• Your security and auth setup doesn't need any changes

The stateless default is there for high-availability deployments where you might have multiple gateway instances behind a load balancer. For your use case (sounds like development/single-instance), stateful sessions will give you the behavior that matches the direct MCP connection.

Hope that clears things up!

[arjavdongaonkar]

Firstly, thank you for the detailed explanation of the Gateway workflow and for creating this amazing tool.
I’ve been digging into the behaviour and wanted to share some observations.

Even with USE_STATEFUL_SESSIONS=true, I noticed that multiple sessions are being created on the MCP server side.
After adding logs to the MCP Python SDK, I saw that all requests sent from the Gateway to the MCP server carry the same mcp-session-id header. However, I also observed a DELETE call that tears down the SSE stream for that session. This, in turn, deletes the transport and forces the creation of a new transport and session.

Interestingly, this behaviour is different when connecting directly (client → server). In that case, if I invoke two tools, I see a single DELETE request only after both calls finish. But through the IBM Context Forge, I see a DELETE after every tool invocation.

This raised a few questions for me:

• Is the IBM Gateway acting as a server, a client, or simply as a proxy?
• Is it maintaining separate sessions with the server and the client?
• When I call session.initialize() or session.listtools(), I don’t see corresponding API calls on the MCP server, yet the client still gets a response through the Gateway. Is this response cached or pre-fetched from an already established session (boot-time or periodic check)?
• I noticed that the mcp-session-id generated/logged on the Gateway side differs from the mcp-session-id generated on the MCP server. Who is responsible for creating this session ID? Are there multiple IDs being tracked?
• How does the Gateway map client sessions to server sessions?
• Why issue a DELETE after each tool call instead of reusing the connection?
• Should server sessions live for as long as client sessions?

Would love to hear your insights on this.