invalid character 'd' looking for beginning of value

[pabloparejo]

Hi team! I am trying to install Postman MCP using the Docker MCP Toolkit but I am not able to do it.
I installed the MCP Server correctly in my Docker and set up the postman.postman-api-key field (Also, I defined an env-level POSTMAN_API_KEY just in case).
But, when I run the Docker gateway, I see this in the logs:

- Reading configuration...
  - Reading registry from registry.yaml
  - Reading catalog from [docker-mcp.yaml]
  - Reading config from config.yaml
  - Reading tools from tools.yaml
  - Reading secrets [postman.postman-api-key]
- Configuration read in 196.007083ms
- Using images:
  - mcp/postman@sha256:e455cdc79afa14a5a3a31bb3299875acd64beff8dc70c94a0f34eb6893449ab9
> Images pulled in 19.429542ms
- Those servers are enabled: postman
- Listing MCP tools...
  - Running mcp/postman with [run --rm -i --init --security-opt no-new-privileges --cpus 1 --memory 2Gb --pull never -l docker-mcp=true -l docker-mcp-tool-type=mcp -l docker-mcp-name=postman -l docker-mcp-transport=stdio -e POSTMAN_API_KEY]
  > Can't start postman: failed to connect: calling "initialize": invalid character 'd' looking for beginning of value
- Watching for configuration updates...
> Initialized in 736.576792ms
> Start stdio server

Versions

Docker version: Version 4.46.0 (204649)
MacOS: 15.5 (24F74)

Not sure if I am doing something wrong or there is an actual bug. If you could help me, I'd appreaciate it.

Thanks!

PS: I tried adding other MCPs and they are working fine inside the Docker MCP Toolkit, so I am assuming it's not a Docker issue

[rubenbaraut]

hi @pabloparejo !

Try generating a new API key in Postman and re-enter it in the MCP Toolkit settings from Docker Desktop or in your env variable.
Finally, do not include extra quotes, spaces, or line breaks in the value, as these may cause parsing errors.
Could you check that the environment variable does not contain any special characters ?

And, last test, could you run this docker run command ?
docker run -i --rm -e "POSTMAN_API_KEY" mcp/postman@sha256:c0da82f3b69203a898f2ccce3a3b875255b2e4cff818b073412497b5c4954ea3

If the issue persists, please let us know here in this thread, and we will work with you to find an alternative solution.

[pabloparejo]

Hi @rubenbaraut,

Thanks again for the quick reply!

While reviewing the API keys I used yesterday, I noticed that I had accidentally added a d at the end of the key the first time I configured MCP. Later, I created a new key, but I kept encountering the same error — that's when I reached out for help 🙏.

Today, I removed all my API keys and started from scratch, but it's still not working within the MCP Toolkit. I tried removing the server, deleting the environment variable, and also removing the postman.postman-api-key setting in MCP Toolkit — but I continue to see the same error:

Can't start Postman: failed to connect: calling "initialize": invalid character 'd' looking for beginning of value

Interestingly, I even get this error when I try to run the gateway without any API key. It makes me wonder whether there’s some caching issue — maybe Docker or the Postman MCP server is still referencing the original key (the one with the extra d) — or if it’s just a coincidence that the error message highlights that specific character.

I ran the command you suggested, and it works fine outside the gateway. However, that means I’d need to manually add the server to Claude, which isn't ideal for my workflow (though it does work).

Since the command is working, I guess this may be an issue with Docker rather than Postman MCP. Unless there's something else you’d recommend trying on your end, feel free to close this issue.

Thanks again for your help! 🙌

[pabloparejo]

Hi @rubenbaraut,

After conducting deeper debugging with Claude Code, I believe I've identified the root cause of this issue. It appears to be related to how the Postman MCP server handles logging during the MCP protocol initialization.

When running the Postman MCP server directly (as you suggested), it works perfectly and loads all 107 tools correctly. However, the server outputs initialization logs to stderr during the MCP handshake:

  [2025-09-25T16:29:08.809Z] [INFO] Loading tools from directory {"toolsDir":"/app/dist/src/tools"}
  [2025-09-25T16:29:08.812Z] [DEBUG] Discovered tool files {"count":107}
  [2025-09-25T16:29:08.814Z] [INFO] Loaded tool {"method":"createCollection","file":"createCollection.js"}
  ...
  [2025-09-25T16:29:08.872Z] [INFO] Server connected and ready: @postman/postman-mcp-server@2.3.3 with 38 tools (minimal)

The issue is that the Docker MCP Gateway expects clean JSON-RPC communication on stdio during the initialization process, but these log messages are interfering with the protocol communication. The "invalid character 'd'" error occurs when the Gateway tries to parse log text (like "[DEBUG]") as JSON instead of the expected MCP protocol messages.

This explains why:

1. The direct Docker command works (no protocol parsing interference)
2. Other MCP servers work fine in the toolkit (they likely have cleaner stdio handling)
3. The error persists even without API keys (the issue happens during initialization, before authentication)

I created this pull request to disable all logs by default, and only show them when --verbose is used

Thanks for your help investigating this! 🙏

[rubenbaraut]

Hi @pabloparejo,

Thank you very much for your PR! it has been extremely helpful in diagnosing the issue.

After reviewing it, we confirmed that the root cause comes from an external library, which is writing errors to stderr without the expected format, at least in VSCode. The error message we observed is:

2025-09-26 12:17:36.246 [error] Client error for command Unexpected token 'd', "[dotenv@17."... is not valid JSON

It appears that this issue has already been addressed by the maintainers:
• motdotla/dotenv#903 (comment)
• dynatrace-oss/dynatrace-mcp#166

Also, we're going to make changes in our MCP to prevent thecalling "initialize": invalid character 'd'error message that you've seen in Claude. It seems to be formatting these error messages improperly on our side.

Once the updated release of dotenv is available, we will proceed to update our mcp integration accordingly.