Hey folks - is there any way to forward a header from the MCP server through to the router? I know you can define static headers, but looking to forward one that is dynamic.
1 Like
Hi @mjfaga, dynamic header forwarding will be included in v1.1. The release date depends on the security review results, but it should be ready by next week. If youād like to take a peek at what it will look like, please see the following PR. Thank you!
Cool - I just found that as wellā¦. you guys happen to have a release candidate I can play with while the official stuff goes through security review?
1 Like
Hi @mjfaga , that sounds like a great idea! Iāll check with the team and get back to you.
Love it. Thank you very much!
Iām currently running the apolloruntime:0.0.25_router2.7.0_mcp-server1.0.0 if it helps.
1 Like
@mjfaga You can download the release candidate using the following command:
curl -sSL https://mcp.apollo.dev/download/nix/v1.1.0-rc.1 | sh
Or, you can download the Docker image with this command:
docker image pull ghcr.io/apollographql/apollo-mcp-server:v1.1.0-rc.1
You can configure using the forward_headers setting in the config file:
forward_headers:
- x-tenant-id
- x-experiment-id
- x-geo-country
Please let me know if this works for you and share any feedback before we ship it next week.
Awesome. Iāll give it a run this evening and confirm back. Thank you!
1 Like
Something seems a bit off to meā¦
Dockerfile.mcp
FROM Package apollo-mcp-server Ā· GitHub
COPY mcp-dev.yaml /data/config.yaml
COPY operations/ /data/operations/
mcp-dev.yaml
I can DM this too you, but itās the one Iām already runningā¦ interesting bits:
transport:
type: streamable_http
address: 0.0.0.0
port: 5000
forward_headers:
- x-test-header
cors:
allow_any_origin: true
methods:
- GET
- POST
- OPTIONS
allow_headers:
- content-type
- x-test-header
- mcp-protocol-version
docker-compose.yml
mcp:
build:
context: .
dockerfile: Dockerfile.mcp
restart: always
command: ['/config.yaml']
ports:
- ā5050:5000ā
environment:
- APOLLO_KEY
- APOLLO_GRAPH_REF
Something off I noticed about the startupā¦ For some reason, the MCP server binds to port 8000 in the containerā¦ If I update my docker-compose.yml port binding to ā5050:8000ā, I can at least hit the MCP server, but then I hit the second issue.
mcp-1 | 2025-10-17T01:36:10.210660Z INFO Starting MCP server in Streamable HTTP mode port=8000 address=0.0.0.0
Also, when using MCP Inspector, despite my CORS config, Iām getting CORS errors. This is the config I use for my current server (but Iām using the apollo-runtime container), so I know it works. Looking at the repo source code, the cors config matches what is in apollo-mcp-server/crates/apollo-mcp-server/src/cors.rs at main Ā· apollographql/apollo-mcp-server Ā· GitHub oddly enough, that is missing allowing OPTIONS requests, so the attempt to actual send the CORS request fails. Seems like you guys should patch that?
I also attempted to run the docker container directly, but that didnāt work either. If Iām passing the config in wrong, let me know 
docker run \
-it --rm \
āname apollo-mcp-server \
-p 5001:8000 \
-v mcp-dev.yaml:/data/config.yaml \
-v operations:/data/operations \
-e APOLLO_KEY=XXXXXXXXXXXXXXXXXXXXXX \
-e APOLLO_GRAPH_REF=XXXXXXXXXXXXX \
āpull always \
Package apollo-mcp-server Ā· GitHub /data/config.yaml
Hi @mjfaga, it looks like there are likely some configuration issues.
For the port configuration, we decided to change the default port from 5000 to 8000 in v1.1. This change is based on feedback from developers who often run into port conflicts because some other tools such as AirPlay and Flask use the same port. This is noted as a breaking change in the release notes:
Regarding CORS, it looks like your configuration doesnāt enable it at all. By default, the Apollo MCP Server has CORS disabled. Please make sure to enable it explicitly:
cors:
enabled: true # Must explicitly enable!
allow_any_origin: true
methods:
- GET
- POST
- OPTIONS
Please check this docs on how to configure CORS with the Apollo MCP Server:
Thanks for explaining the port change. Still, itās odd that it seems to be ignoring my config explicitly telling it to run on port 5000, no?
My bad. I enabled it and that resolved part of the problem.
Iām not seeing the Access-Control-Allow-Origin header come back from the CORS OPTIONS response still though:
Iāve tried all of the documented config options, starting with:
cors:
allow_any_origin: true
And then:
cors:
origins: ``http://localhost:6274`` # MCP Inspector Only
And then:
cors:
match_origins: ā^http://localhost:6274$ā # MCP Inspector Only
Hmmā¦ 
the X-Amzn-Requestid header suggests the server is running behind AWS. Could you try reproducing locally to confirm the behavior is the same? If it only happens on AWS, there may be a service-level CORS setting you need to enable.
I canāt reproduce the issue with your port setting being ignored. Just in case, could you try using a different port, like 5050? Iāve seen many folks having issues with 0.0.0.0:5000 in various environments for unexpected reasons, which is why we want to move away from port 5000.
I think this was a me issueā¦ I rebuilt the image with āno-cache and then reran MCP inspector and the CORS issues are gone, as is that AWS header. Iām still seeing a different issue though. Working through it.
OK - so everything is up and running and custom headers are passing through successfullyā¦
Most of the issues I encountered I think were from bouncing from the apollo-runtime container to directly running only the MCP (e.g. I didnāt have that CORS enabled flag set, but for some reason, on the apollo-runtime, I didnāt need it). I also ran some docker stuff I had to fix as a result of that change (e.g. host.docker.internal vs. localhost).
Looks like there is a new header we need to pass to CORS as well that I had to quickly debug through x-custom-auth-headers that I didnāt realize I would need to set up and configure.
None-the-less, this is awesome, thank you very much! Appreciate you guys banging out an RC that I can play with. Iām off to the races!
1 Like
Does this allow for passing through an Authorization header? We have bearer tokens (JWT) which we need to pass through to our graphql endpoint. Iāve tried adding āAuthorizationā to the āallow_headersā, but still getting authorization issues using the MCP inspector with the a configured authorization header value.
Hi @mtinnes, this feature is designed for forwarding non-sensitive metadata like A/B testing, feature flagging, geo information from CDNs, or internal instrumentation.
We strongly recommend against using header forwarding for passing through credentials such as API keys or access tokens. Forwarding credentials can introduce confused deputy vulnerabilities where your GraphQL API may incorrectly trust headers as though they were validated by the MCP Server.
We support OAuth for authorizing MCP clients in accordance with the MCP specification:
Please check the following docs for more security best practices:
Understood, but Iām wondering how we work with server-side MCP implementations, by that I mean the backend server is interfacing with the MCP, not the user via a client (ie Claude Desktop). We have users of our SaaS service already authenticated with our IdP and already have a valid token usable with our GraphQL endpoint. The user interfaces with our SaaS frontend which in turn makes a request to an Anthropic library utilizing the Apollo MCP server. Since the MCP server is running server-side we donāt have a method for re-authenticating with OAuth specifically for the Apollo MCP server. The only solution I can see if for the existing token be provided to the MCP server which can then be utilized in the GraphQL calls. Since itās all performed server-side, I donāt see an issue with doing it this way.