MCP Server Not Connecting? Check Transport, Auth, and Config

When an MCP server is not connecting, the problem usually sits in one of three layers: the server did not start, the transport between client and server is misconfigured, or authentication is failing. Working through those layers in order is faster than guessing.

This checklist is client-neutral: the steps apply whether you are using Claude, Cursor, VS Code, or another MCP-compatible app. If the connection breaks while your team is mid-project, a tool like fenbs can restore the shared context so the next session starts from where the last one stopped.

Step 1: confirm the server started

An MCP server that is not running cannot accept connections. Check these first.

• Run the server command manually in a terminal. Does it start without errors? Copy the exact command from the client config and run it yourself.
• Check the process list. Is the server process actually running, or did it crash silently?
• Look at the server's own logs. Startup errors often appear there and not in the client's error messages.
• Confirm the working directory. Some servers read relative paths at startup. If the config launches from the wrong directory, file paths fail and the server exits.

Step 2: check the transport layer

MCP supports two main transports: stdio (the client launches the server as a child process and communicates over stdin/stdout) and HTTP (the client connects to a running server over a URL). A misconfiguration in either causes a connection failure that looks like an authentication or permission problem.

For stdio transport, the most common issue is the wrong command or missing arguments in the client config. Paste the command into a terminal to confirm it produces a running process. Also confirm the client config uses the right transport type: stdio not http, or vice versa.

For HTTP transport, check the URL and port. A server on localhost:3000 is not reachable at localhost:8080. Also check whether the server requires HTTPS and whether a firewall or proxy is blocking the port. For background on how servers and transports fit together, see MCP server architecture.

Step 3: diagnose authentication failures

If the server starts and the transport is correct but the client still cannot connect, authentication is the likely cause.

• For Bearer token auth: confirm the token is present in the request header and has not expired. Some clients require a restart after a token change.
• For OAuth: check whether the authorization flow completed and the client stored a valid access token. A missing or revoked token causes a 401 that looks like a connection error.
• For local-only servers: confirm the server is not requiring auth it was not configured to handle. An unexpected auth challenge will silently block the connection.
• Check the server log for the auth error. A 401 or 403 in the server log confirms the transport is working but auth is failing.

Step 4: review the config file

Many connection failures trace to a small error in the config file: a trailing comma that breaks JSON parsing, a wrong field name, or a path that does not exist on the current machine.

Open the client's MCP config file and validate it. Run it through a JSON linter if it is JSON, or check YAML indentation if it uses YAML. Then compare every path and URL against what actually exists on disk and in your network.

The MCP server configuration guide covers the standard config fields and common mistakes in each client.

Step 5: isolate the client

Config errors and auth errors have similar symptoms in the client UI. A startup failure that exits the server before it binds to the transport looks identical in the client to a firewall blocking the port. The server log tells you which one it is, and working through the five layers in order avoids misdiagnosing the cause and spending time on the wrong fix.

If you cannot tell whether the problem is in the server or the client, try connecting from a second client. If a different client connects successfully, the first client's config or version is the issue. If neither connects, the server is the problem.

For VS Code specifically, the separate article on MCP server not showing in VS Code covers the additional discovery and trust checks that VS Code requires.

How to do this with fenbs

fenbs is one example of an MCP server. If you are troubleshooting a fenbs connection specifically, these steps apply directly.

1. Create a free account if you have not already, and go to Integrations to find the setup guide for your AI app.
2. Follow the guide for your client. fenbs uses OAuth: click Connect, sign in in a browser, and approve the access. No token pasting required.
3. If the connection fails after approving, check that the client restarted or refreshed its server list after the OAuth flow completed.
4. Check Settings in fenbs to confirm the assistant token was created and is active. A revoked token causes a 401 on every request.
5. If the problem persists, open the client's MCP log or developer console for the specific error. A transport error and an auth error look different and point to different fixes.