How it works
xentfi-mcp-http starts an Express server implementing the MCP Streamable HTTP transport on POST /mcp (plus a GET /healthz health check). It runs in stateless mode: every request creates a fresh MCP server + client pair bound to that request’s credentials, then tears it down.
This means:
- One process can safely serve many different agents/organizations at once — credentials never leak between requests.
- There is no server-side session state to persist or scale; you can run multiple replicas behind a load balancer with no sticky-session requirement.
- Each request is a little more expensive than a long-lived stdio connection (fresh server per call) — the right trade-off for a multi-tenant deployment, and negligible in practice.
Running it
Authenticating requests
EveryPOST /mcp call must carry the caller’s agent credentials as headers:
x-xentfi-api-key is also accepted as an alternative to Authorization, for clients that can’t set that header freely. Requests without a resolvable API key receive a 401 JSON-RPC error before any XentFi API call is attempted.
Deployment recipes
Put this behind a TLS-terminating reverse proxy — MCP clients like ChatGPT require HTTPS. Fly.io, Render, and Railway all provision HTTPS automatically if you point them at the Dockerfile above.
Testing your deployment
xentfi_* tools.
Programmatic embedding
If you’re already running your own Express (or other Node HTTP) server and want to mount XentFi’s MCP tools at a custom path alongside other routes, usecreateXentfiMcpServer() directly instead of the xentfi-mcp-http binary:
Next steps
ChatGPT
Wire this deployment into a ChatGPT custom connector.
Error Handling
How auth and policy failures surface over HTTP.

