What is an MCP client?

The part of an AI application that holds one connection to one MCP server, sends it requests such as tools/list and tools/call, and hands the results to the model. The application creates one client per server.

Is an MCP endpoint the same as an API endpoint?

It is a URL like any API endpoint, but it speaks one fixed protocol, JSON-RPC over HTTP, with a fixed set of methods. You do not read its documentation to learn the calls; the client asks the server for its tool list.

What is the MCP initialize request?

The first message a client sent on protocol revisions up to 2025-11-25. It carries the client's protocol version, capabilities and name; the server answers with its own, and the client confirms with an initialized notification. The 2026-07-28 revision puts the same information on every request and adds server/discover.

Do I need my own MCP server to use MCP?

No. Connecting a client to an existing server, such as OBTO's, needs only the URL and a sign-in. You need your own server when you want a model to reach a system nobody has exposed yet.

← All articles Guide

What an MCP client, an MCP server and an MCP endpoint are

OBTO Team · 21 October 2026

Client, server and endpoint get used as if they were interchangeable. In the Model Context Protocol (MCP) they are three different pieces. The client is the piece inside your AI application that holds a connection to one server. The server is the program that offers tools, data and prompt templates over that connection. The endpoint is the URL a remote server answers on. The rest of this page is detail on those three sentences, with OBTO's own endpoint as the worked example.

The MCP client

The specification calls the AI application the host: Claude Desktop, Claude Code, ChatGPT, Cursor, VS Code. The host creates one MCP client per server it connects to, and each client keeps a dedicated connection to its server. When Claude Desktop is connected to a filesystem server and to OBTO, it is running two MCP clients. You never install a client on its own; it ships inside the app. What you configure is the list of servers the host should open clients for.

The MCP server

An MCP server is a program that provides context to clients, wherever it runs. It exposes three kinds of things: tools the model can call, resources the model can read, and prompts the host can offer the user. A local server runs on your machine and talks over standard input and output; the filesystem server is the usual example. A remote server runs elsewhere and talks over HTTP, so many clients can share it. The messages are JSON-RPC 2.0 either way. The plain-English guide to MCP servers goes further on the three primitives.

The MCP endpoint

"Endpoint" is not a term the specification defines. In practice it means the URL of a remote MCP server, the thing you paste into a connector dialog. OBTO's is https://app.obto.co/ms/mcp. The client sends HTTP POST requests to it, each carrying one JSON-RPC message, and the server answers in the response body or over a server-sent event stream. One URL, one server, as many clients as sign in.

Three messages happen on every new connection.

Hello. The client announces the protocol version it speaks and what it can do. Servers on protocol revisions up to 2025-11-25 receive this as an initialize request and answer with their name and capabilities; the client then sends an initialized notification. From the 2026-07-28 revision the same facts ride on every request, and a client may ask server/discover up front instead. Most servers in use today, OBTO's included, answer initialize.
What have you got. The client sends tools/list and receives every tool's name, description and input schema. This list is what the model sees. A tool that is not in it cannot be called.
Do this. When the model picks a tool, the client sends tools/call with the tool's name and arguments. The server runs it and returns content, usually text.

Remote endpoints normally require sign-in. The specification uses OAuth 2.1 for HTTP transports: the first request without a token gets a 401 with a pointer to the server's metadata, the client registers or identifies itself, the user approves in a browser, and from then on every request carries a bearer token in the Authorization header.

Worked example: connecting to OBTO

In Claude, ChatGPT, Claude Code or Cursor, add a connector, paste https://app.obto.co/ms/mcp, choose OAuth, and sign in with Google when asked. That sign-in is the OAuth step above. The first tool worth calling is obto_whoami: it returns who you are, your workspace domain, the server version and the apps you can reach. From there the client has the catalog, and the model can build, read and change an app through tool calls.

The same URL answers on every OBTO cluster, so two connections are told apart by the domain whoami returns, never by the address. A second form of the endpoint, https://app.obto.co/ms/mcp?scope=tenant, serves a connection only the tools, resources and prompts that one tenant has published, plus whoami. It is a smaller catalog for the people who use a tenant's app, and it is a catalog filter rather than an access control: each tool still runs its own checks. Which tools appear in tools/list is the subject of the tool list is the boundary.

Where the MCP documentation lives

OBTO's setup steps per client are on the getting started page, and connecting an MCP server to Claude covers the first failed call. The specification, the SDKs and the reference servers are at modelcontextprotocol.io. The current revision is 2026-07-28, and the SDK a server was built with decides which handshake it answers.