Overview
UMCP supports array-based environment variables that automatically rotate through multiple values using a round-robin strategy. This feature is designed for distributing API requests across multiple API keys, tokens, or credentials, helping you:- Stay within rate limits by spreading requests across multiple accounts
- Implement simple load balancing for API usage
- Rotate credentials for security or compliance reasons
Configuration Syntax
Environment variables can be defined as either a single string or an array of strings. Fromconfig.ts:12:
Single Value (Static)
Array Values (Rotating)
How Round-Robin Works
In-Memory State
UMCP maintains rotation state in memory using a nested Map structure. FromroundRobinEnvPool.ts:7:
- Outer map:
providerId→ provider state - Inner map:
envKey→ current index
- Each provider has independent rotation state
- Each environment variable key has its own rotation index
- State is not persisted to disk
Pool Creation
The round-robin pool is created at server startup. FromroundRobinEnvPool.ts:32-73:
Rotation Algorithm
For each environment variable:- Check if the value is a string or array
- If string: Use the value directly
- If array:
- Get the current index for this provider/key (default: 0)
- Select the value at
currentIndex % arrayLength - Increment the index for next time:
(currentIndex + 1) % arrayLength - Log the rotation event
roundRobinEnvPool.ts:50-62:
Discovery Values
During tool discovery, UMCP uses the first value from each array to test provider connectivity. FromroundRobinEnvPool.ts:16-30:
Detecting Rotating Environment Variables
UMCP checks if any provider has rotating env vars. FromroundRobinEnvPool.ts:9-14:
Logging and Security
Rotation events are logged with masked values to avoid exposing secrets. FromroundRobinEnvPool.ts:56-62 and logger.ts:
maskSecret function shows only a preview of the credential:
Example Usage
Basic Rotation
Configuration:- Request 1: Uses
key-account-1 - Request 2: Uses
key-account-2 - Request 3: Uses
key-account-3 - Request 4: Uses
key-account-1(cycles back) - Request 5: Uses
key-account-2 - And so on…
Multiple Rotating Variables
- Request 1:
key-1+secret-1 - Request 2:
key-2+secret-2 - Request 3:
key-1+secret-1(both cycle)
Mixed Static and Rotating
API_KEY rotates; other variables remain constant.
State Behavior
Startup Behavior
When UMCP starts:- All rotation indices initialize to
0 - First tool discovery uses the first value in each array
- First actual tool call uses the first value and increments the index
Per-Provider Isolation
Each provider maintains independent rotation state. Consider this configuration:- Calls to
search.brave-1.*rotate betweenkey-aandkey-b - Calls to
search.brave-2.*rotate betweenkey-candkey-d - The two providers don’t affect each other’s rotation state
Restart Behavior
Rotation state is not persisted. When UMCP restarts:- All indices reset to
0 - Rotation starts over from the first value in each array
- External load balancers
- API gateway services
- Database-backed credential rotation
Per-Invocation Rotation
Rotation happens per provider invocation, not per tool call. This means:- If a provider exposes multiple tools, they share the same credential for that invocation
- The credential rotates when the provider is invoked again (for any tool)
Error Handling
Empty Arrays
The schema prevents empty arrays. Fromconfig.ts:12:
- Arrays must have at least one element
- Each element must be a non-empty string
Fallback for Missing Values
If an array value is somehow undefined, UMCP falls back to an empty string. FromroundRobinEnvPool.ts:51:
Use Cases
Rate Limit Distribution
API provider allows 100 requests/minute per key:Cost Distribution
API charges per request. Rotate across multiple billing accounts to spread costs:Geographic Distribution
Rotate between regional API keys for data residency:Development vs. Production Keys
Use rotation to test with multiple environments:Limitations
- No persistence: State resets on server restart
- No coordination: Multiple UMCP instances don’t share rotation state
- No paired rotation: Each variable rotates independently
- No weighted rotation: All values are equally likely
- No health awareness: Failed keys still rotate in (unless provider reconnects)
Best Practices
- Use consistent array lengths: Makes rotation patterns more predictable
- Test all credentials: Ensure every key in the array is valid before deployment
- Monitor usage: Watch logs to verify rotation is working as expected
- Plan for restarts: Don’t rely on rotation state persisting across restarts
- Document ownership: Keep track of which keys belong to which accounts
Example Log Output
When rotation occurs, you’ll see logs like:- Confirm rotation is working
- Debug credential issues
- Audit API key usage
- Track which keys are being used