Allow Custom Environment Variable Mapping in Apollo MCP Server

[riginoommen]

The Apollo MCP Server currently enforces a strict environment variable naming convention:

APOLLO_MCP_{SECTION}__{SUBSECTION}__{PROPERTY}

This tightly couples environment variable names to the internal YAML configuration hierarchy. While this approach ensures structure and consistency, it creates friction for users deploying across diverse environments (e.g., Kubernetes, Docker, CI/CD systems, or enterprise infrastructure with custom naming policies).

Problem:

1. Rigid Naming Pattern:
   All environment variables must follow the APOLLO_MCP_ prefix and double-underscore (__) nesting rule.
2. Integration Overhead:
   Many systems have predefined or shorter naming schemes that don’t align with this pattern, forcing users to manually rename or duplicate variables.
3. Reduced Portability:
   Teams migrating configurations or integrating multiple services face compatibility issues because variable names cannot be customized or remapped.
4. No Alias Support:
   The system does not allow mapping alternative environment variable names to existing configuration keys.

Example Limitation:
Currently, to configure the OTLP tracing endpoint, only this variable is supported:

APOLLO_MCP_TELEMETRY__EXPORTERS__TRACING__OTLP__ENDPOINT

It’s not possible to use a shorter or existing environment variable such as:

CUSTOM_OTEL_ENDPOINT

Proposed Solution:
Introduce an optional env_mapping section in the configuration file to allow flexible aliasing or remapping of environment variables.

Example proposal:

telemetry:
  # Service name for telemetry data identification
  service_name: "rhg-apollo-mcp-server"
  # Service version for telemetry data
  version: "1.2.3"
  # Telemetry exporters configuration
  exporters:
    # Metrics export configuration
    metrics:
      # OTLP (OpenTelemetry Protocol) exporter for metrics
      otlp:
        # Protocol: "grpc" or "http/protobuf" (default: grpc)
        protocol: "grpc"
        endpoint: ${env.CUSTOM_OTEL_ENDPOINT}

The MCP server would resolve these custom mappings first, falling back to the default naming convention if not found.

Benefits:

• Enables flexible integration with any deployment environment
• Reduces configuration duplication and human error
• Maintains backward compatibility with existing naming patterns
• Simplifies adoption for teams already using standard environment variables

Environment:

• Apollo MCP Server Version: 1.0.0

Summary:
The current environment variable naming pattern (APOLLO_MCP_{SECTION}__{SUBSECTION}__{PROPERTY}) is too prescriptive for real-world use cases. Supporting a user-defined mapping system would make configuration more portable, maintainable, and developer-friendly.