Running Multiple Local Instances of the Jama Connect MCP™ Server with Separate OAuth Configurations

Published Date: May 5, 2026
Audience: Everyone
Products and Versions Covered: 

• Jama Connect MCP™

Summary

This article explains how to run multiple local instances of the Jama Connect MCP™ Server using separate OAuth configurations. This setup is commonly used when customers need to connect different Jama Connect® environments, accounts, or AI tooling contexts independently.

Customers may encounter conflicts when multiple MCP server instances share the same OAuth configuration directory, token cache, or local runtime environment. This behavior can become more noticeable when using tools such as GitHub Copilot, Claude Desktop, Windows Subsystem for Linux (WSL), Docker containers, or combinations of local and virtualized environments.

This article provides guidance for isolating OAuth configurations and runtime environments so that multiple MCP server instances can operate independently on the same workstation or development environment.

Important OAuth and Redirect URI Considerations

The current Jama Connect MCP™ OAuth implementation is designed primarily around locally executed MCP clients that authenticate through a localhost callback flow.

Typical supported MCP authentication behavior assumes:

1. The MCP server launches locally
2. Browser-based authentication occurs locally
3. OAuth redirects back to a localhost callback endpoint
4. The local MCP process receives the callback and establishes the session

Most current MCP tooling integrations, including locally executed clients and development tooling, rely on localhost redirect URIs such as:

http://127.0.0.1/oauth/callback

Because of this architecture, customers using hosted or cloud-based AI tooling may encounter authentication limitations if the tooling requires a remote or externally hosted OAuth redirect URI instead of a localhost callback.

Examples may include:

• cloud-hosted AI agents
• hosted automation platforms
• remote OAuth consumers
• cloud-based copilots or orchestration tooling

These hosted environments may not be able to complete OAuth authorization flows that depend on localhost callback handling.

Additionally, different execution environments may handle localhost resolution, loopback networking, credential storage, and callback routing differently, particularly when using:

• Windows native environments
• WSL
• Docker containers
• virtual machines
• AI tooling launching MCP from different execution contexts

When troubleshooting OAuth or session establishment issues, validate that:

• each MCP instance uses the correct OAuth configuration,
• redirect URIs match the expected runtime behavior,
• localhost callback endpoints are reachable from the execution environment,
• and cached tokens or shared configuration directories are not causing conflicts.

Resolution

Each Jama Connect MCP™ Server instance should maintain its own:

• OAuth configuration
• token storage location
• runtime environment
• port assignment (if applicable)
• working directory

Separating these resources helps prevent authentication conflicts, token overwrites, and unexpected session behavior.

Recommended Best Practices

1. Create Separate Configuration Directories

Create a dedicated configuration directory for each MCP server instance.

Example:

~/mcp-prod-config
~/mcp-dev-config
~/mcp-sandbox-config

Store each environment’s OAuth credentials and configuration files separately.

2. Use Separate Environment Variables

Define environment variables independently for each MCP instance.

Example:

MCP_CONFIG_DIR=~/mcp-prod-config

and

MCP_CONFIG_DIR=~/mcp-dev-config

This ensures that each server references its own OAuth and token configuration.

3. Isolate Runtime Environments

When possible, run each MCP instance in a separate execution context, such as:

• Separate terminal sessions
• Separate Docker containers
• Separate WSL distributions
• Separate virtual environments

This reduces the likelihood of conflicts in shared caches, networking, or file systems.

4. Use Unique Local Ports

If running multiple local MCP services simultaneously, assign unique ports to each instance.

Example:

Instance 1 → localhost:3000
Instance 2 → localhost:3001

Verify that ports do not overlap with those used by other local applications or services.

5. Validate OAuth Redirect URIs

Ensure that each OAuth configuration matches the expected redirect URI and local callback behavior for that specific MCP instance.

Mismatched redirect URIs may cause:

• authentication failures,
• repeated sign-in prompts,
• incomplete OAuth authorization,
• or failed session establishment.

Current MCP implementations are primarily intended for locally executed clients that can receive localhost OAuth callbacks.

6. Consider Tooling and Virtualization Differences

Customers running MCP from different environments may experience different networking or filesystem behavior, including:

• Windows native environments
• WSL
• Docker containers running inside WSL
• AI tooling launching MCP from different execution contexts

These environments may handle:

• loopback networking,
• localhost resolution,
• credential storage,
• filesystem paths,
• or OAuth callback handling differently.

Validate that each runtime environment can independently access its intended OAuth configuration and callback endpoint.

Troubleshooting Tips

If issues persist:

1. Stop all running MCP instances.
2. Clear cached authentication tokens for the affected environment.
3. Confirm each instance uses a unique configuration directory.
4. Verify that environment variables are correctly scoped.
5. Confirm that local ports are not duplicated.
6. Reauthenticate each instance independently.

Additional Resources

• Jama Connect Cloud Model Context Protocol (MCP)
• Success Programs
• Success Catalog
• Datasheets
• Request a Solution Offering or Training from the Success Catalog

Feedback:
We welcome your input! Please sign in to leave any comments, suggestions, or ideas for improvement below.