Trouble getting ms-365-mcp-server to stay up in Docker (Windows 10 / Docker Desktop) – tried multi-stage build, disabled Keytar, still exits immediately

[ju-scho]

1  What I’m trying to do

Run the Softeria ms-365-mcp-server inside the same Docker Compose stack that already hosts an n8n instance, so that n8n can call the MCP server at http://localhost:3333/….

2  Environment

OS	Windows 10 Pro 22H2 (19045.5854)
Docker Engine	25.0.5 (Docker Desktop 4.31.0)
Compose CLI	v2.36.2
Node inside image	node:20-slim
Repo commit	Softeria/ms-365-mcp-server 50e7243 (current main)

3  Compose excerpt

services:
  # … other services (n8n, open-webui, nginx) …
ms365-mcp:

image: ms365-mcp-local:latest

build:

context: "./ms-365-mcp-server"          # repo cloned next to compose.yml

dockerfile: Dockerfile.ms365

container_name: ms365-mcp

environment:

- PORT=3333

- LOG_LEVEL=verbose

- KEYTAR_DISABLE=1                      # avoid libsecret/keytar issues

volumes:

- ./ms365_mcp_data:/root/.config/ms-365-mcp-server

ports:

- "5333:3333"

restart: unless-stopped

networks:

default:

name: mcp-net

4  Current Dockerfile.ms365 (multi-stage)

##########  STAGE 1: build (TS → JS) ################################
FROM node:20-slim AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci                                  # incl. dev-deps → tsc present
COPY . .
RUN npm run build                           # produces ./dist
##########  STAGE 2: runtime ########################################

FROM node:20-slim

RUN apt-get update -qq 

&& apt-get install -y --no-install-recommends libsecret-1-0 

&& rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY package*.json ./

RUN npm ci --omit=dev                       # prod deps only

COPY --from=builder /app/dist ./dist
ENV KEYTAR_DISABLE=1 

PORT=3333 

LOG_LEVEL=verbose
EXPOSE 3333

CMD ["node", "dist/server.js"]

5  What already didn’t work

Attempt	Result
Use Softeria’s pre-built image	Crash-loop: Error: libsecret-1.so.0 … ERR_DLOPEN_FAILED (keytar)
Add libsecret in Alpine / Debian	Same error
Rebuild keytar from source	Build ok after installing dev-pkg, but upstream Node (musl) then crashes with __vdso_gettimeofday
Switch to fresh node:20-slim + KEYTAR_DISABLE=1	Image builds, container immediately exits (restart loop)
Add multi-stage build (npm run build)	Image builds, container still exits
Change CMD → dist/server.js	Container restarts, no logs; interactive node dist/server.js returns instantly with exit 0, nothing listens on :3333

6  Symptoms right now

• docker compose up -d ms365-mcp → container restarts every ~1 s, no log lines.
• Interactive run:

  root@…:/app# node dist/server.js
  # returns instantly, exit code 0, no output
  

• Port 5333 closed (curl localhost:5333 → connection refused).

7  Questions for the community

1. Correct entry point ? Repo ships dist/{server,cli,index}.js. Which file is the proper headless HTTP server?
2. Does it expect extra CLI args / env vars (beyond PORT, LOG_LEVEL) before it actually starts listening ?
3. Anyone running MCP server in Docker (node:slim / Debian bookworm) without keytar – which CMD do you use?
4. Would you recommend sticking to Softeria’s original container and debugging keytar/libsecret instead?

Any working Compose snippet or hint is highly appreciated – I’ve spent the whole weekend and clearly miss one simple switch. 🙏

---

Thanks in advance!

[eirikb]

Hi

Why are you listening to a PORT? There is no http server here, only stdout/stdin.

That being said you can just run it directly?

Dockerfile:

FROM node:slim

RUN apt-get update && apt-get -y install libsecret-1-0

command:

docker run --rm -it node-with-libsecret-image npx -y @softeria/ms-365-mcp-server

What's up with libsecret? It's used by keytar, which we use to store credentials safely after login (with device code flow). So for docker you probably want to handle that in a persistent way.
Note that the server will fall back to json file if it fails to store credentials - but the initial error from keytar doesn't seem to be handled. I guess we could handle that, but forcing some security could also be nice.

---

Edit:
Perhaps for things like docker we could add client secret. Since you now can bring your own Entra app, you can also bring your own secret. The server use msal so it's just a property.
Not crash on missing libsecret, and allow setting client secret.
I see a lot of other MCP servers use client secrets, and I really just wanted a more user friendly approach to authentication, where the device code flow seems to work great. But for docker, perhaps secret is better.
What do you think?

[ju-scho]

Hi,

thank you very much for your quick and detailed response!

Let me clarify my use-case and also respond to your questions:

• My goal: I want to connect Microsoft 365 as an MCP server to n8n (self-hosted, running in Docker), so that n8n agents and workflows can access the tools (e.g., Calendar, Mail, OneDrive, etc.) from the MCP server.
  n8n has a built-in "MCP Client Tool" node, but it expects the MCP server to provide an HTTP/SSE endpoint (as most @modelcontextprotocol/server-* servers do).
• I understand that ms-365-mcp-server is designed to run as a pure STDIO MCP server, and that there is no HTTP server or port exposed. That is why I tried to use a separate MCP-Proxy (for example TBXark/mcp-proxy) to bridge between the STDIO process and HTTP/SSE.
• Test: I tested a Setup, where I ran the server outside of docker in a"normal" environment and it started, however I could not connect n8n via the proxy with the MCP Server. I used the device code flow for login, and it works locally as described. I do not have any issues with keytar or libsecret in my test setup because I run everything on Windows with persistent storage.
• What happens: The MCP server and proxy start successfully, all tools are listed, and the proxy exposes an HTTP endpoint (e.g., /mcp on port 9090). (I think) I can access the endpoint from other machines on the network (I get a 404, which might be normal for a non-SSE request), but when I try to connect with n8n's MCP Client Tool node, I just get "Could not connect to your MCP server" without further details.
  The proxy log shows no incoming requests, or in some proxy versions only logs SSE requests, not normal GETs. Curl and browser tests always reach the proxy endpoint and produce the (expected?) 404.
• About client secrets: For my use case, the device code flow works fine for my test environment, since I do not need unattended service-to-service auth. But I agree, for Docker or headless operation, having client secret support is a useful option!

My main question: Is it possible that ms-365-mcp-server (via a standard MCP proxy) is currently not fully compatible with n8n's "MCP Client Tool" node, because it only supports STDIO (not HTTP/SSE) and the proxy does not bridge all required protocol features? Or is there any known working example of using ms-365-mcp-server with n8n or another HTTP/SSE-based MCP client?
If not, is there a plan or workaround to expose this MCP server via HTTP in a way that n8n expects (e.g. special headers, handshake)?

Thanks again for your work! The MCP ecosystem is very promising, and having MS365 integration in workflows would be a great feature.

[eirikb]

I can add another protocol. But do you need SSE? It seem this is deprecated (ref). Does n8n only support a deprecated protocol, or can it use Streamable HTTP?

[eirikb]

An update here.

I've added Streamable HTTP transport. It can be enabled by passing --http [port] (default is 3000) to the server.

npx @softeria/ms-365-mcp-server --http 7000

It will then have /mcp endpoint.

I'm closing this discussion now. If it doesn't work with n8n it could be because they only support SSE, and not Streamable HTTP - but SSE is deprecated so I don't think I will add it. Better to find other workarounds in n8n.

---

Also note; I've considered adding client secret a bit more, and for now I will not do that. Because it really complicates things a lot more than one might initially think. This would mean running company-level requests, not user-level requests.
So all endpoints would have to be changed from /me - like endpoints, with delegated permissions, to user-with-id endpoint with more enterprise-like permissions.
Perhaps later, if enough people want it (or myself), but I don't need this, and I doubt other end-users need this yet.