MCP Server Endpoints: URLs, Transports, and Connection Checks

An MCP server endpoint is the address — either a URL or a local process — that a client connects to when it wants to use the server's tools. The form that endpoint takes depends on the transport the server uses, and the two standard transports work quite differently.

Getting the endpoint right is the first step in connecting any AI app to an outside tool. Tools like fenbs are remote servers with a URL; a custom server you build for your own machine is a local process. Both types appear in the same client configuration, but they need different information to connect.

The two standard transports

The MCP specification defines two transports. Stdio (standard input/output) connects a client to a server that runs as a child process on the same machine. Streamable HTTP connects a client to a server at a persistent URL over a network.

A stdio server has no URL. The client starts it, exchanges messages through the process's stdin and stdout, and shuts it down when the session ends. A Streamable HTTP server has a URL, runs persistently, and can serve multiple clients at once.

Both are described in the mcp server spec. The transport you need depends on where the server runs and who needs to use it.

When to use a remote URL

A remote URL makes sense when the server needs to be accessible from multiple clients, multiple team members, or from clients that cannot run a local process — like a mobile app or a browser-based AI.

Remote servers also make sense for services that already run in the cloud: a company knowledge base, a CRM integration, or a shared project context like fenbs. The server runs once; each client connects to it by URL and authenticates to prove its identity.

fenbs connects at https://fenbs.ai/api/mcp. Any supported AI client that authenticates with OAuth can use that URL to read and update your shared project context. No local installation is needed.

When to use a local process

A local stdio server is the right choice for tools that access local files, local databases, or services that are only available on your machine. A server that reads your local development environment, your file system, or a locally running database should run locally.

Local servers are also simpler to set up for personal use. You do not need a hosting environment, a public IP address, or OAuth infrastructure. The client starts the server process, uses it, and stops it.

The trade-off is that local servers are per-machine. A colleague cannot use the same local server; they need their own installation. For team use, a remote server is worth the extra setup.

How a Streamable HTTP endpoint works

A Streamable HTTP server receives MCP requests as HTTP POST requests to a single endpoint path (often /mcp or /api/mcp). The response is either a single JSON document for simple requests, or a streamed response for requests that return incremental content.

The client needs one URL — the endpoint path — and credentials. For OAuth-protected servers, the client discovers the authorization server through RFC 9728 metadata at /.well-known/oauth-protected-resource. The client signs in in a browser, gets an access token, and sends it in the Authorization header of each MCP request.

For a remote server that uses a static API key instead of OAuth, the token goes in the same header. Check the server's documentation for the exact format it expects.

How stdio transport works

A stdio server is configured in the client with a command to run, not a URL. Claude Desktop, for example, reads a configuration file where each server entry has a command field (the executable to run) and an args field (the arguments to pass).

{
  "mcpServers": {
    "my-local-server": {
      "command": "node",
      "args": ["/Users/alice/my-server/index.js"],
      "env": {
        "API_KEY": "from-environment"
      }
    }
  }
}

The path in args must be absolute. The env field passes environment variables to the server process. Sensitive values like API keys belong in the environment, not hardcoded in the config file.

Verifying an endpoint before connecting

For a remote Streamable HTTP server, the simplest check is a GET request to the endpoint URL. Many servers return a description of their capabilities — or at least a 200 or 401 response — at that URL. A 404 or a connection error tells you the URL is wrong before you spend time debugging a client configuration.

For an OAuth-protected server, check that the /.well-known/oauth-protected-resource path returns a valid JSON document. That confirms the authentication discovery is working correctly.

For a stdio server, run the command manually in a terminal with the same arguments you put in the config file. If it starts without errors and waits for input, the process itself is working. If it crashes immediately, read the error output before adding it to the client.

How to do this with fenbs

1. Create a free account and connect your AI app to fenbs over MCP from Integrations.
2. The fenbs endpoint is https://fenbs.ai/api/mcp. Your client will discover the OAuth metadata automatically. Sign in in the browser when prompted.
3. For other MCP servers you connect, add their endpoint URLs and startup commands as context notes in fenbs so your team can find them without re-reading each tool's documentation.
4. When a server's URL or configuration changes, update the context note. Add a note explaining what changed and when, so the history is visible.
5. If a connection stops working, check the context note first for the last known working configuration before investigating the server itself.