Connecter des clients distants

Your server is built, proxied, and healthy. Now real clients connect to it over the internet using its public URL. 🌍

Remote clients no longer launch a local process. Instead you hand them the server's public URL, usually ending in your /mcp endpoint.

In a host like Claude, you register a remote server by giving its URL instead of a command, so the host connects over HTTP.

A protected server expects an access token. Clients attach it in an Authorization header on every request they send.

Your own Python client connects the same way: open a streamable HTTP session against the remote URL rather than spawning stdio.

Remote or local, the connection begins with the same initialize handshake where client and server agree on version and features.

After connecting, the client lists tools, resources, and prompts over the network exactly as it would for a local server.

Network hops add delay that local stdio never had. Expect a little latency and design tools so a slow call does not stall the user.

The internet is flaky, so connections drop. A good client will reconnect and resume rather than failing the whole session.

Confirm the full path works: client to proxy to server and back. A successful tool result proves the deployment is truly live. ✅

The big payoff of going remote is sharing: one hosted server can serve teammates, agents, and apps all at once.

How does a remote client connect to your deployed MCP server?

Remote clients connect to your public URL with an auth token, run the same handshake and discovery, and let one server serve many. 🎉