You can open a server's login page and still have an MCP client that cannot connect. Your browser and the process making MCP requests may be on different networks. Signing in proves something about the browser's path; it does not prove that the client has the same path.
Start by locating the client, then check reachability, authorization and account state separately. This guide uses the Datahase-maintained WhatsApp MCP project as a concrete example. It covers HTTP connections, using the project's public documentation and the official Tailscale and MCP specifications.
Locate the process that makes the request
Write down two locations: where WhatsApp MCP runs, and where the MCP client runs. A desktop interface does not, by itself, tell you whether its connector makes requests locally or from a remote service. Check that client's connection documentation.
The address 127.0.0.1 refers to the machine making the request. On your laptop it means your laptop; on a remote server it means that server. A loopback endpoint copied from one machine is therefore not a remote connection address. The project's remote-access guide makes this distinction explicit.
| Where requests originate | A suitable route | What to verify |
|---|---|---|
| On the same computer as the server | A loopback endpoint, with the documented client configuration | The service is listening at that address and port |
| On another permitted tailnet device | Private HTTPS through Tailscale Serve | Both devices have the required network access |
| In a remote service without a route into your tailnet | An approved public HTTPS route, or a supported private connection | The actual requesting service can reach it, and application authorization remains required |
Tailscale Serve shares a service within a tailnet and respects its access-control rules. Tailscale Funnel makes the selected service reachable from the public internet. OAuth controls access to the application; it does not create a network route.
For example, a laptop on your tailnet might open a private Serve address successfully while a cloud connector times out against the same address. The difference is the request's origin. A private route supported by the connector may solve that; public exposure is a separate deployment decision.
Check the existing route before changing it
For a Tailscale deployment, run these read-only commands on the host where Tailscale serves the application:
tailscale serve status
tailscale funnel status
Read the configured hostname, port and forwarding target. These commands inspect configuration; they do not publish a new service. Compare the result with the endpoint shown in WhatsApp MCP's Connect client page. The project setup guide describes the intended Serve and Funnel arrangements.
A similar-looking hostname is not enough to establish whether a route is private or public. Check the active configuration. Avoid repeatedly rerunning setup while trying to understand an existing deployment: changing the route can hide the original failure and change who can reach the server.
Test HTTP reachability without adding credentials
From the machine where the client runs, inspect an unauthenticated response. Replace this reserved example hostname with your endpoint; do not put a token in the URL:
curl --silent --show-error --include --max-time 10 \
'https://mcp.example.com/mcp'
If the connector runs in a remote service, a command on your laptop only tests your laptop's path. Use the provider's connection diagnostics to investigate the remote path.
Treat the response as a clue about the failing layer:
| Observation | What it tells you to check next |
|---|---|
| DNS failure, refused connection or timeout | Hostname, route, listener and service availability |
| Certificate error | The requested hostname and the certificate presented for it |
| 401 with a Bearer challenge | The protected resource is asking for authorization; inspect its advertised metadata |
| 403 | Identify which application or proxy refused the request and why |
| 404 or 405 | Endpoint path and HTTP method, before drawing conclusions about authentication |
An HTTP response proves that something answered, not necessarily that it was the intended MCP application. Check the responder and endpoint. A browser GET or this curl request is also not an MCP initialization test.
Read the authorization challenge
For an HTTP MCP server using the authorization specification, a 401 can be the expected start of sign-in. The MCP authorization specification defines protected-resource metadata discovery and bearer-token use. It also prohibits access tokens in URI query strings.
Look for the WWW-Authenticate header and its resource_metadata address. An illustrative challenge looks like this:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
Use the location advertised by your server; do not assume every deployment uses the example path. Check that metadata and the authorization endpoints are reachable from the relevant client and browser environments. Getting past DNS or TLS is a prerequisite, not evidence that the OAuth exchange completed.
Keep the three connections distinct
WhatsApp MCP has separate steps for the owner's admin session, the MCP client's authorization, and linking a WhatsApp phone. The project's OAuth guide explains these roles and how to copy the client endpoint.
That separation gives you a useful test sequence:
- Confirm the client can reach the intended HTTP endpoint.
- Complete the documented client authorization flow.
- Ask the assistant to list linked WhatsApp accounts.
- Choose an account, then request a small read, such as recent chat names.
If the connection succeeds but the account is absent, inspect phone linking and account state instead of immediately changing OAuth. If a request is refused, investigate the reported permission or server error rather than removing authentication.
Read-only testing is a limited action, not a limited permission grant. The current OAuth guide says approval covers reading, sending and requested analysis for current and future linked accounts. Review that scope before approval. The README also notes that a send tool sends immediately; an account-list request is enough for the first functional check.
Collect evidence that narrows the next question
A useful support report includes the client location, server location, access mode, endpoint path, exact error and time, and whether HTTP, OAuth and account listing each worked. Keep tokens, authorization codes, admin sign-in codes and private message content out of the report.
Those observations let you ask a precise question: which layer failed, and from which machine? That is a much smaller problem to investigate than “MCP does not work.”
For the project's setup and upstream attribution, see our open-source page. For a product that uses a different device-to-device connection model, read the Tetherly product study. If you are designing a connection between systems, explore our API and integration services.
Documentation checked on 4 November 2026.